Review

Don't use when:

• Only config/docs changed (no code to review)
• Single-line trivial fix

5. The implementation reviewer is ALWAYS dispatched
6. Check for a plan: Look for plan context to pass to the plan-adherence reviewer. Repos accumulate multiple plans over time, so disambiguation matters — using the wrong plan produces bogus findings. Check these sources in priority order:
   • Explicit argument (highest priority): If the user passed plan context as an argument (e.g., /code-review-pipeline "plan: ..." or a plan slug/path), use that directly. Read the file if a path was given.
   • Branch-matched plan: List all plans/*/state.json with "phase": "SELECTED". If the current git branch name contains a plan slug (e.g., branch feat/user-auth matches plans/user-auth/), use that plan. This is the most common case — branches are usually named after the feature they implement.
   • Diff-matched plan: If no branch match, compare changed file paths against each selected plan's scope (read approaches.json to understand what each plan covers). Pick the plan whose scope best overlaps with the changed files.
   • plan.md or PLAN.md in the repo root — use as fallback only if no plans/ directory exists.
   • If multiple plans match equally or no plan is found, do NOT guess. Skip the plan-adherence reviewer and note "Multiple plans found, pass a plan slug to disambiguate" or "No matching plan found". If plan context is found, add plan-adherence to the category set and store the plan content to pass to the reviewer.
7. Deduplicate categories into a set of reviewers to dispatch

Dispatch map:

Announce: "Dispatching reviewers: {list}. Each reviewer will cross-validate with Codex via codex MCP tool."

Spawn all applicable reviewers as teammates in a single request. Use Opus for each teammate.

For EACH teammate, provide:

1. The reviewer role name (from the dispatch map)
2. The full git diff
3. The list of files relevant to that reviewer
4. The repository root path (from git rev-parse --show-toplevel)
5. Instructions to return JSON in the standard output format

Instructions for each teammate:

You are a {reviewer-role} teammate. Review the following code changes. Return your findings as JSON.

## Repository root
{repo_root}

## Changed files
{file_list}

## Diff
{diff_content}

When calling the codex tool, pass `cwd: "{repo_root}"` and use repo-relative @ file references.

For the plan-adherence reviewer only, also include:

## Plan context
{plan_content}

Where {plan_content} is the plan text discovered in the DIFF phase (the selected approach JSON, markdown plan, or user-provided plan text).

Each teammate will:

1. Perform their Claude-based domain review
2. Call codex MCP tool for Codex cross-validation (with cwd set to the repo root)
3. Validate the Codex response before merging — empty, non-JSON, or error-text responses mean Codex-unavailable
4. Merge findings with classification (AGREE/CHALLENGE/COMPLEMENT) only if Codex returned valid JSON
5. Return unified JSON with engine tags

Critical and High findings

For each critical/high finding:

1. Read the file at the specified line
2. Apply the recommendation to fix the issue
3. Report what was fixed

Medium and Low findings

Report as suggestions in a summary table:

## Review Summary

**Reviewers dispatched:** implementation, test, ui (Opus, dual-engine)
**Files reviewed:** 5
**Findings:** 2 critical, 1 high, 3 medium, 1 low
**Cross-validated:** 2 findings confirmed by both Claude and Codex

### Cross-Validated (flagged by both Claude and Codex)
- [critical] src/auth.ts:42 — SQL injection via string interpolation (AGREE)
- [high] src/api.ts:15 — Uncaught promise rejection (AGREE)

### Fixed (Critical/High)
- [critical] src/auth.ts:42 — SQL injection via string interpolation -> switched to parameterized query
- [high] src/api.ts:15 — Uncaught promise rejection -> added try/catch

### Suggestions (Medium/Low)
| Severity | Agent | File | Line | Issue | Recommendation | Engines |
|---|---|---|---|---|---|---|
| medium | implementation | src/utils.ts | 23 | Potential null dereference | Add null check | claude |
| medium | implementation | src/utils.ts | 25 | Missing boundary check | Validate input range | codex |
| low | architecture | src/config.ts | 8 | Magic number | Extract to named constant | claude, codex |

### Plan Adherence
**Plan:** plans/feature-slug (Approach 1: "Name")
**Completeness:** 4/5 items implemented
- [x] JWT authentication middleware
- [x] Route protection
- [ ] Token refresh endpoint (**missing**)
**Deviations:** 1 justified (middleware instead of decorator)
**Scope creep:** None

### Stale Documentation
- [high] README.md:42 — `AUTH_SECRET` env var renamed to `JWT_SECRET`
- [medium] docs/api.md:15 — Missing `/auth/refresh` endpoint from API reference

### Missing Tests
- Test error path when fetchUser throws in src/auth.ts:42
- Test empty array input in src/utils.ts:23

If no findings above confidence threshold: report "Review complete — no issues found."

Converted and distributed by TomeVault — claim your Tome and manage your conversions.