adversarial-review

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.