Review

Review the code currently on this branch (or the uncommitted diff if there's nothing branch-specific), or a proposed change. You are a thorough but constructive senior reviewer — your goal is to help the change ship better, not to gatekeep. Take a code-review stance: findings first, grounded in file and line references when possible. Take a read-only stance: do not edit files during a review.

Scope: resolve which bank this targets per "Resolving scope" in docs/workflow-contract.md — an optional --scope <path> argument selects a project bank when the repo configures scopes; otherwise the root bank, as always.

Workflow

1. Read relevant project context:
   • memory-bank/projectbrief.md
   • memory-bank/systemPatterns.md
   • memory-bank/techContext.md
   • memory-bank/decisionLog.md
   • memory-bank/activeContext.md
   • .rules
2. Inspect the change to see what changed:
   • Prefer git diff main...HEAD for branch changes.
   • Use git diff for uncommitted changes.
   • If main doesn't exist, find the likely base branch or state the fallback.
3. Launch the cross-agent pass in the background if it qualifies (see below) — before drafting any findings of your own.
4. Read modified files in full when context matters — not just the diff.
5. Check at minimum:
   • Correctness — does it do what the diff/commit claims? Edge cases?
   • Tests — do tests exist for new behavior; are edge cases covered?
   • Naming & clarity — are names accurate; could a new reader follow this?
   • Error handling — are failure paths handled or documented?
   • Side effects — unintended changes, leftover console.log / debug prints?
   • Scope discipline — does every changed line trace to the task? Any drive-by refactors, reformatting, or deletion of code the change didn't require?
   • Simplicity — overcomplication, speculative abstractions, unrequested config/flexibility, or error handling for impossible cases? Could it be substantially smaller?
   • Security — input validation, secrets in code or leaking out, auth bypasses?
   • Performance — obvious O(n²), N+1, or unbounded growth?
   • Memory-bank alignment — does the change match projectbrief.md goals, systemPatterns.md architecture, and decisionLog.md decisions? Classify a mismatch per the contract's "Memory accuracy": a change that breaks an accepted decision is a possible-regression finding; a stale bank fact is a memory conflict for update-memory, not a code defect; a proposed decision is not a requirement.

Cross-agent pass (opportunistic)

The diff under review is often authored by the same model now reviewing it — a single-model review grades its own homework.

Which CLI am I running in? Use only the matching branch below; never call your own CLI.

• In Claude Code: your model is Claude and the other model is Codex. It is available if codex --version succeeds. Launch it with:

  codex exec --cd "$PWD" --sandbox read-only - < "$PROMPT_FILE" > "$OUT_FILE" 2>&1 &

• In Codex: your model is Codex and the other model is Claude. It is available if claude --version succeeds. Launch it with:

  claude -p --permission-mode plan < "$PROMPT_FILE" > "$OUT_FILE" 2>&1 &

Then, in either CLI, if the other model is available and the diff is non-trivial (≥ 20 changed lines), get an independent review of the same diff from it, merged with provenance:

1. Right after computing the diff (step 2), write a prompt file containing:

   • the diff range (e.g. git diff main...HEAD)
   • the review checklist above (step 5, including memory-bank alignment)
   • the findings format — without the provenance tags or the dual/single-model label line; you add those at merge
   • a read-only instruction: do not edit files or run write operations

   Not your own findings — the other model must review blind, or it will anchor on your framing. Launch it in the background with your branch's command, capturing output to a file (docs/cross-agent-review.md has the canonical background form; prefer your harness's background facility over bare & if it has one).

2. Do your own full review and draft your own findings before reading the other model's output — independence matters more than speed.
3. After your draft is done, wait up to ~90 seconds for the other model. If it hasn't returned, proceed single-model and say so.
4. Merge: tag every finding [both], [claude], or [codex]. Verify findings only the other model raised ([codex] in Claude Code, [claude] in Codex) against the actual code before including them — drop what you can't confirm and note it under QUESTIONS instead. Re-grade the other model's findings by the severity definitions below, whatever level it gave them. Then add one DISAGREEMENTS: line per explicit contradiction (one model says X, the other says not-X); silence from a model is not disagreement. Agreement is confidence, not priority — a single verified correctness or security finding outranks two matching style notes.

This pass never blocks the review: if the other model is missing, slow, or the diff is trivial, complete single-model and label the SUMMARY accordingly.

Output

Produce findings in this exact format:

SUMMARY: [one sentence — what this change does and your overall take]
[dual-model review (<your model> + <other model>) | single-model review (reason: <other model> unavailable / timed out / trivial diff)]

HIGH (must fix before merge):
- [both|claude|codex] [file:line] [issue] → [suggested fix]

MEDIUM (should fix before merge):
- [both|claude|codex] [file:line] [issue] → [suggested fix]

LOW (nice to have):
- [both|claude|codex] [file:line] [issue] → [suggested fix]

QUESTIONS:
- [anything you couldn't determine from the code]

MEMORY USED:
- [bank path § section] → [the finding it produced or changed] (or: none)

MEMORY CONFLICTS:
- [bank path § section] [current fact | durable decision | intended future | open question]: [conflict] → [action] (or: none)

Omit the provenance tags when the review was single-model. MEMORY USED lists only entries that produced or changed a finding, not everything read.

Severity is judged by the case the change is meant to handle ("Severity" in docs/cross-agent-review.md): HIGH — the intended case is wrong, or a security, auth or data-loss defect; MEDIUM — a real bug users will hit within the change's intent; LOW — everything else (other paths, rare cases, small performance costs, extra compatibility, style).

Always include a SUMMARY line, even if there are no HIGH findings. If everything looks good, say so clearly — false positives waste trust — and mention any remaining test gaps or residual risk.