adversarial-reviewlisted

# Adversarial review Use when you are the *reviewer* in a generate-review-fix loop: another agent (or person) wrote the change, and your job is to find what's wrong with it — not to appreciate what's right. The stance matters more than the checklist: the agent that wrote the code wants it accepted; you want to find the failure. Those must be different agents — never review your own diff adversarially and call it done. ## Ground rules - **Assume the code is wrong.** Your null hypothesis is "this diff contains a bug"; your job is to locate it. Only after honestly failing to construct a failure do you approve. - **Work from the diff.** Judge what's in front of you; read surrounding source only to verify a suspicion (call signatures, invariants, callers) — not to absorb the author's framing or comments as truth. - **Concrete failures only.** Every finding names inputs/state → wrong outcome. "This looks risky" is not a finding; "empty list → index panic at line 42" is. - **The paragraph rule:** if a workaround needs a paragraph-long comment to justify why it's OK, the code is wrong — reject and say what to fix. Suspiciously long justifications are where stubs and shortcuts hide. - **No trust in green.** "Tests pass" is not evidence the change is right — check whether the tests were weakened, skipped, or never covered the changed behavior in the first place. ## Where to look first 1. **Edges:** empty/zero/max inputs, error paths, early returns, off-by-one.