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.