Adversarial review — presume it broken, find where

Adversarial review — presume it broken, find where

A normal review reads code and looks for reasons to approve it. An adversarial review starts from the opposite prior: this was just built, it is presumed broken, and the job is to find where. The builder believes in their work — that belief is exactly the blind spot. So the reviewer must be incentivized to find failure, not confirm success, and must work without the builder's context so it cannot inherit the builder's assumptions.

This skill is the canonical adversarial-review protocol for ATLAS. Reach for it autonomously after building anything non-trivial, before shipping, or when handed unfamiliar code to harden.

When to use it — and which review

• Use this when you want the thing attacked: a feature you just finished, a build before delivery, a flow you suspect is fragile, an unfamiliar codebase you must trust.
• Use /code-review instead for a fast, conservative pass over a diff or PR — it statically reads the change for bugs and cleanups, scores confidence, and never runs the app. That is the right tool for routine change review.
• The line between them: /code-review reads; adversarial-review runs. This skill presumes breakage, fans out diverse hostile lenses in clean contexts, and reproduces findings against the live target before believing them. Heavier, empirical, used deliberately.
• Scale down, don't skip: for a small change one hostile reviewer is enough. Don't fan out a fleet to attack a typo fix — deliberating everything ships nothing.

The four invariants (what makes a review adversarial)

1. Presumed-broken mandate. Every reviewer gets one instruction: "this was just built and is presumed broken; find where." Never "check if it looks ok."
2. Context isolation. Reviewers run in clean contexts (separate subagents) — they get the target and the mandate, not the build's rationalizations. A separate context window is the closest thing to a genuine second opinion.
3. Empirical reproduction. A finding is a hypothesis until reproduced against the real target. Run it. A finding that can't be reproduced is an opinion, not a bug.
4. Senior triage. Reproduce before fixing, fix what's real, re-verify the fix, and name the false alarms. The report is only trustworthy if it admits what wasn't real.

How to run it

1. Frame the target and scale. Name what's under review (a diff, a feature, a running app, a whole codebase) and how to exercise it (commands to run, URLs/flows to walk, entry points). Pick reviewer