| name | adversarial-review |
| description | Cheap-model adversarial verification pass for the end of every implementation phase and before any merge. Framing beats model tier — a low-effort model with the right question finds real bugs the expensive authoring model missed. |
Adversarial Review (Cheap-Model Pass)
Proven event: a low-reasoning-effort model reviewing code written by a frontier model found a real cross-module bug (normalization asymmetry between a writer's strip().lower() and a reader's bare lower()). Not because the cheap model was smarter — because:
(a) seam bugs span modules the author only saw locally,
(b) adversarial framing points the searchlight,
(c) verifying a named weakness is far cheaper than generating a feature.
When
- End of every implementation phase, before declaring done
- Before any merge to main
- After any data analysis (adversarial math check)
- When ANY agent claims completion (see inverted direction below)
Prompt templates (these exact framings found real bugs)
No-op hunt — highest yield for new features:
"Feature X was just implemented (files: ...). Name three distinct, concrete conditions under which it has ZERO effect — each for a different mechanistic reason, citing exact lines. 'The feature is disabled' doesn't count."
Refute-the-diff:
"You are a brutally honest reviewer. Review this staged diff for bugs, production failure modes, silent data corruption, missing tests, and maintainability problems. Focus: [domain]. Do not praise."
Crash-timing — for anything concurrent or scheduled:
"Components A and B can run at the same instant. Explain the mechanism preventing conflict, then construct one concrete crash/timing scenario where work is duplicated or lost, and state whether it corrupts data or only wastes work."
Adversarial math audit — for analyses:
"You are an independent adversarial reviewer. Do not praise. Find mistakes in the reasoning, math, classification thresholds, or proposed next steps."
Rules
- Reviewer ≠ author (different model or at least different session).
- Bound the reviewer's scope. Reviewers asked for whole-package verdicts reject defensively; one review = one diff or one named weakness, evidence inlined.
- A verdict without evidence is fabrication. Require the review to quote what it examined; discard evidence-free verdicts in either direction (a "PASS" with no evidence is how a real 104-PR disaster got its fake approval).
- Verify every finding against the current checkout before acting — cheap reviewers also hallucinate (one cited code already deleted on the branch).
- Surviving findings become fix commits or documented accepted-risks. The report must say what was checked; silence is not an outcome.
Claimed-done verification (same skill, inverted)
When any agent claims completion, verify adversarially before relaying. Real failure modes and their checks:
- "Fixed the data flow" but the write path never reached the backend (404) → drive the real path end-to-end.
- "Reviewed the design" but only syntax-checked → open the artifact visually.
- "Already resolved" from a stale base commit → check the worker's base against the target branch.
