adversarial-code-review

Dispatch fresh-context reviewer subagents that receive only the diff, a written contract, and an adversarial prompt, never the author's reasoning. Each reviewer attacks from a distinct lens such as correctness, tests, or security, and findings are verified by execution in a git worktree.

Send every finding to a skeptic subagent whose job is to refute it by executing the failure scenario in an isolated worktree. A finding is only CONFIRMED with a reproduction command and observed output; otherwise it is reported as PLAUSIBLE or dropped as REFUTED.

Skip it for in-flight design decisions, mechanical changes like renames or formatting, and generated code. For diffs under roughly 50 lines with no risky areas, collapse the panel to one correctness reviewer plus one verifier instead of the full panel.

Yes, reviewers and verifiers run in an isolated git worktree so they can build, run, and test the change. If worktrees are unavailable, it falls back to read-only mode in the current checkout and discloses that verification quality is degraded.

Model reviewers generate plausible-sounding findings that do not reproduce because they only read code without executing it. This process treats reviewer output as hypotheses and requires a skeptic to reproduce each one with a command and output before it counts.

At most two. Each cycle re-runs the original finding's reproduction against the fix and re-reviews only the fix diff. A branch still producing confirmed findings after two cycles is escalated to the user rather than ground through a third cycle.