ADVERSARIAL_REVIEW.md — the open standard for adversarial review

Every team that uses coding agents has tried some version of the same prompt: "now review your change carefully before merging." It does not work, and the failure mode is worse than no review at all — it produces a review-shaped object. The agent re-reads its own diff, confirms its own intent, and reports "looks good." Nobody found a bug; nobody looked for one. The output has the format of scrutiny with none of the function, and because it exists, humans tend to skip the pass they would otherwise have done.

The root cause is that the instruction lives nowhere. A prompt is forgotten the moment the session ends; the next session, the next agent, the next contributor starts from zero. There is no artifact that outlives the chat, nothing that says this repository expects its changes to survive adversarial review — and nothing that defines what such a review even means here.

This is the exact gap AGENTS.md and CLAUDE.md closed for working style. Those files solved "how should an agent behave in this repo" by making the answer a committed, versioned artifact instead of a hope. Review discipline needed the same treatment, and ADVERSARIAL_REVIEW.md is it: an open standard for declaring how adversarial review is done in a repository.

The standard is one file, ADVERSARIAL_REVIEW.md, dropped at the repo root alongside AGENTS.md. Agents that support the repo-convention mechanism pick it up automatically; nothing is tied to any single vendor's tool. The file binds every future session, human or agent, to the same protocol:

• Review as an adversary, not a linter. Assume the change is guilty until proven innocent. Every finding must name a concrete trigger — a code path read, a command run, a reproduction. A hypothetical failure scenario with no trigger is an UNVERIFIED item, not a finding.
• Independent passes, one lens at a time. Each lens is a separate pass; findings from different passes are never blended into a generic list.
• Verify before claiming. Evidence is something the reviewer actually produced, quoted inline — not "(log attached)". A suspicion that could not be settled is reported as UNVERIFIED with what was attempted, never silently dropped and never promoted to a finding.
• Fix-forward only after review. CRITICAL and HIGH findings are fixed and the resulting diff is re-reviewed before the work is called done. A review of unreviewed new code is not done.

Adopters customize a Repo-specific rules section — invariants that must never regress, known weak spots that always get a second pass, commands the reviewer must run — while the portable protocol itself must not be weakened. The repo declares its own rules instead of inheriting generic ones, which is what turns "a review" into this codebase's review.

The core of the standard is the lens list. A complete review covers every core lens, and the verdict names each one as COVERED or SKIPPED with a one-line justification — a silent skip is a failed review:

• security — injection, authn/authz gaps, secret handling, dependency confusion, tamper-evasion of integrity guarantees;
• correctness — edge cases, error paths, races, broken invariants, unhandled states;
• spec-compliance — behavior that diverges from the documented contract; tests that don't test what they claim;
• performance — complexity regressions, unbounded growth, allocation hot paths, latency and bloat;
• abuse — ways the feature can be turned against its intent: spam, forgery, downgrade, replay, griefing;
• operational — deploy and migration hazards, observability gaps, the rollback story;
• governance — signoff requirements actually enforced, verified commits, issues before PRs, license and version hygiene.

Findings carry a four-level severity taxonomy — CRITICAL, HIGH, MEDIUM, LOW — with definitions short enough to enforce and a stated anti-inflation rule: a reviewer who cries wolf trains maintainers to ignore the report; a reviewer who under-rates trains them to skip it. Every report ends with a per-lens verdict that either lists findings or states what was exercised and found clean — paths read, commands run. A bare "clean" claim is explicitly not a verdict.

That last property is the one we care about most, because it is what makes review output machine-checkable. "Checked and clean" has to name the check, the same way our scan recordings name the exact inputs that reproduced — a claim without its evidence is just another vibe.

A standard about review discipline that was not itself adversarially reviewed would be an empty claim, and the project knows it. v1.0.0 was battle-tested by a 347-agent adversarial review of the standard itself — 46 content units run independently through all seven lenses — and the findings are published, not tidied away: docs/review-2026-10-17.md. The dominant theme, reported as HIGH by the swarm: the standard preached review discipline while its own repo defined no contributor process. The governance gap was real, so it was fixed — issues before PRs, cryptographically verified commits, and an NCO signoff (a named reviewer of record) on every merge to main. That is the self-application loop working in public, and it is the strongest argument for the standard: run under its own rules, it found its own weakest point first.

The protocol is stable under semantic versioning at v1.0.1, MIT licensed, and community-governed: take the file, edit the repo-specific section, ship it under your own terms, and propose improvements back.

Two ways in, both cheap:

1. Declare it

   Copy the canonical file into your repo root, fill in the repo-specific rules, and commit. Every agent that reads repo conventions picks it up from then on. The template is at github.com/awdemos/adversarial-review, and the project site adversarial-review.com has the quickstart.

2. Run it on demand

   Install the bundled adversarial-review skill into your agent's skills directory and say run an adversarial review. The skill implements the v1.x protocol — all core lenses, the evidence rule, the severity taxonomy, per-lens verdicts — and defers to any ADVERSARIAL_REVIEW.md it finds in the repo, so declared rules always win over defaults.

We ship adversarial testing as a service, and we still consider this table stakes: the discipline a repo declares for itself is the floor, not the product. Our agents attack the code; the standard is what makes sure the review of that code is not theater. If your repo has an AGENTS.md, it should have one of these next to it.