Skip to content
Back to News
guide
code-review
workflow

Setting Up CKB for Code Review Workflows

By CKB Team

Code review is where CKB shines. Instead of manually tracing through files to understand a change, your AI assistant can instantly tell you who owns the code, what's affected, and who should review it.

This guide walks through setting up CKB for code review workflows.

Quick Setup

Configure CKB with the review preset:

{
  "mcpServers": {
    "ckb": {
      "command": "npx",
      "args": ["@tastehub/ckb", "mcp", "--preset=review"]
    }
  }
}

The review preset includes 27 tools: everything in core plus ownership and diff tools.

Review Workflow Example

Let's walk through reviewing a PR that modifies the payment processing system.

Step 1: Understand the Change

User: "Summarize PR #234 - it touches the payment module"

AI: [calls getDiff for the PR]
    [calls explore on affected directories]

"This PR modifies 4 files in the payment module:
- checkout.go: New retry logic for failed transactions
- refund.go: Updated error handling
- types.go: New TransactionStatus enum value
- checkout_test.go: 3 new test cases

The changes are focused on transaction resilience."

Step 2: Assess Impact

User: "What's the blast radius?"

AI: [calls prepareChange on modified symbols]

"Impact analysis:
- checkout.ProcessPayment is called by 8 handlers
- The new enum value affects 3 switch statements
- 12 tests cover the modified code (all passing)

Risk score: 45 (Medium)
- High churn area (+23 commits this month)
- Good test coverage mitigates risk"

Step 3: Find the Right Reviewers

User: "Who should review this?"

AI: [calls getReviewers for affected files]

"Suggested reviewers:
1. @alice - 67% ownership of checkout.go, last commit 3 days ago
2. @bob - 45% ownership of refund.go, payment domain expert
3. @carol - Wrote the original transaction retry system

@alice is the primary owner and most familiar with recent changes."

Step 4: Check for Concerns

User: "Any red flags?"

AI: [calls analyzeCoupling for modified files]
    [calls getHotspots]

"Potential concerns:
1. checkout.go is a hotspot (23 changes in 30 days) -
   consider if this change adds to technical debt

2. Tight coupling between checkout.go and billing.go -
   changes here often require billing updates

3. No changes to API documentation despite new status code"

Key Review Tools

getOwnership

Returns who owns a file or directory based on git history:

{
  "file": "internal/payment/checkout.go",
  "owners": [
    { "author": "alice", "percentage": 67, "lastCommit": "2026-01-20" },
    { "author": "bob", "percentage": 23, "lastCommit": "2026-01-15" }
  ]
}

getReviewers

Suggests reviewers based on ownership, recency, and expertise:

{
  "suggested": ["alice", "bob"],
  "reasoning": {
    "alice": "Primary owner (67%), recent activity",
    "bob": "Domain expert, reviewed similar changes"
  }
}

getOwnershipDrift

Identifies when ownership has shifted—useful for catching knowledge silos:

{
  "file": "internal/payment/checkout.go",
  "drift": {
    "historical_owner": "david",
    "current_owner": "alice",
    "transition_period": "2025-06 to 2025-09",
    "risk": "david may have undocumented knowledge"
  }
}

getDiff / getFileDiff

Retrieves structured diff information with semantic understanding:

{
  "files_changed": 4,
  "additions": 127,
  "deletions": 34,
  "modified_symbols": [
    { "name": "ProcessPayment", "type": "function", "change": "modified" },
    { "name": "TransactionStatus", "type": "enum", "change": "extended" }
  ]
}

Review Checklist Prompts

Here are prompts you can use in your review workflow:

Understanding the change:

  • "What does this PR actually change?"
  • "Explain the purpose of the changes in [file]"
  • "What's the difference between the old and new implementation?"

Impact assessment:

  • "What breaks if this change has a bug?"
  • "What tests cover these changes?"
  • "Are there any untested code paths?"

Ownership and reviewers:

  • "Who owns the code being modified?"
  • "Who should review this PR?"
  • "Has ownership of this area changed recently?"

Quality checks:

  • "Are there any red flags in this PR?"
  • "Does this change follow the patterns in the rest of the codebase?"
  • "Is there any dead code being introduced?"

Integrating with Your Review Process

GitHub PR Comments

Use CKB analysis to write better PR comments:

User: "Write a review summary for PR #234"

AI: [aggregates previous analysis]

"## Review Summary

### Changes
- Added transaction retry logic with exponential backoff
- Extended TransactionStatus enum for retry states
- Updated error handling in refund flow

### Impact
- Medium risk (score: 45)
- 8 downstream callers affected
- Good test coverage (12 tests)

### Recommendations
1. Consider adding metrics for retry frequency
2. Document the new status codes in API docs
3. Verify billing.go doesn't need updates (tight coupling detected)

LGTM with minor suggestions."

Automated Review Triggers

For teams using CI/CD, CKB can provide review context automatically:

# .github/workflows/pr-review.yml
- name: CKB Analysis
  run: |
    ckb analyze-pr ${{ github.event.pull_request.number }} \
      --output=comment \
      --include=impact,ownership,suggestions

Tips for Effective Reviews

  1. Start with impact - Know the blast radius before diving into code details
  2. Trust the ownership data - The suggested reviewers usually know the code best
  3. Watch for hotspots - Frequently changed files deserve extra scrutiny
  4. Check test coverage - CKB tells you which tests cover the changes
  5. Look for coupling - Changes in tightly coupled areas often need coordinated updates

What's Next

CKB 8.1 will add reviewChange, a compound operation that combines diff analysis, ownership lookup, impact assessment, and reviewer suggestions into a single call.

Links: