phrazzld/code-review

/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.