/adversarial-review

name: adversarial-review
description: Adversarially review something just built — presume it is broken and find where. Use after implementing a feature, finishing a build, or before shipping, or whenever ATLAS or Boss wants a hostile second opinion on a diff, a running app, or a whole codebase. Spawns clean-context reviewers with opposing lenses (correctness, security, empty-world) and reproduces every finding by running the target before believing it. Distinct from /code-review, which statically reads a diff and never runs the app.

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 count by stakes: 1 for a small change, 3–5 lenses for a feature or build.

2. **Fan out hostile reviewers in clean contexts.** Spawn subagents, each with the presumed-broken mandate and **one lens**, blind to each other. Choose lenses that fit the target — typically:

• **Correctness** — edge cases, off-by-one, race conditions, broken flows, state that lies
• **Security** — injection, authz/authn holes, secrets in code, unvalidated input, SSRF/path traversal
• **The empty world** — first run, zero data, no config, expired token: does it still stand up?
• **Data integrity** — partial writes, lost updates, migrations, constraints that don't hold
• **Failure & limits** — network/dependency failure, timeouts, huge inputs, concurrent users
• **UX seams** — error messages, loading/empty states, the run instructions a stranger needs

(One-shot work dies at the seams and the empty world far more than the happy path — weight those.)

3. **Reproduce every finding.** Before fixing anything, run the target and confirm the failure actually happens. Capture the evidence (output, screenshot, failing command). Unreproducible → demote to "unconfirmed," don't fix on faith.

4. **Triage like a senior.** Fix what reproduced, re-run to confirm the fix closed it (and opened nothing new), and record what looked like a bug but wasn't. If a fix opens a real design fork, invoke `free-will`.

Output — the report

One honest summary:

• **Confirmed & fixed** — what broke, the reproduction, the fix, the re-verification.
• **Confirmed & deferred** — real but consciously not fixed now, and why (goes on the gap list).
• **False alarms** — flagged then disproven. Listing these is what makes the rest credible.
• **Residual risk** — what this pass could not exercise, and what would attack it next.

Never report "no issues found" from a read alone — that claim requires having *run* the lenses and reproduced nothing. Report what you actually exercised, not what you assume holds.