---
name: code-review
description: |
  Dispatch-shaped code review: fan the diff out to fresh-context reviewers
  across diverse providers and model families, synthesize, fix blockers,
  re-review until clean. Use when: "review this", "code review", "is this
  ready to ship", "second-model review". Trigger: /code-review, /review.
argument-hint: "[branch|diff|files]"
---

# /code-review

You are the marshal. Read the diff, dispatch diverse fresh-context
reviewers, synthesize, fix blockers, loop until clean. The authoring agent
never ships on its own review — that is the one hard rule.

## Dispatch

1. **Scope = the diff.** `git diff <base>...HEAD` (default base: the repo's
   default branch). Classify what changed: API, UI, security surface, data
   model, infra, docs.
2. **Fan out in parallel, decorrelated.** Native subagents for focused
   lenses (pick 2–4 that fit the diff: correctness, security, simplicity,
   tests); peer harness CLIs (`/roster`) for cross-model judgment — a
   different model family has decorrelated failure modes; `thinktank
   review` when installed for a wide bench. If the harness can run a
   large-scale background orchestration where reviewers adversarially
   cross-check each other's findings before reporting, a substantive diff
   is a natural fit — that scale costs tokens, so routine diffs don't get
   it. Reviewers get the diff, the acceptance oracle, and a risk lens —
   **never the author's reasoning trail.**
3. **Aim reviewers at production embarrassment, not nitpicks.** Tell each
   one what to ignore (style, naming, speculative "consider…") as
   explicitly as what to find.

## What reviewers hunt

Plausible-but-wrong is the failure mode of model-written code:

- Stub or specification-shaped implementations that pass tests but don't work
- Wrong complexity (O(n²) hiding behind a clean interface)
- Tests that never invoke the changed entrypoint (adjacent green lanes)
- Missing invariant checks that only matter at scale or under concurrency
- Unnecessary abstraction — wrappers, modes, layers that don't earn their keep
- Swallowed errors, magic fallbacks, internal mocks

If the diff adds or changes an executable path (CLI, script, migration, job),
someone must run it once or cite the gate that does — otherwise it's an
**unverified runtime path** and blocks Ship. If the diff touches a visual or
user-facing surface, at least one reviewer exercises it live.

## Synthesize and verdict

Dedupe across reviewers; rank **blocking** (correctness, security, unverified
runtime path) > **important** (architecture, test strength) > **advisory**
(everything else). Blocking findings get fixed and the fix re-reviewed —
full pass, not a spot-check. Max 3 fix-review iterations, then escalate to
the operator with the open findings. Ship / Don't-ship is the lead's call on
the reviewers' evidence; advisory findings never block.

## Gotchas

- **Monoculture.** Same-model subagents alone are groupthink with extra
  steps. Substantive diffs get at least one other model family.
- **Reviewing the repo instead of the diff.** Scope discipline keeps
  findings actionable.
- **Treating all findings equally.** Severity ranking is the marshal's job;
  a wall of undifferentiated comments is review theater.
- **Skipping re-review after fixes.** A fix can introduce the next bug;
  blockers get a fresh pass.
