adversarial-review-quick

Adversarial Review — Quick Panel

Overview

The same hostile review as the full adversarial-review skill, on as few reviewers as the change strictly needs. Each reviewer runs as a fresh subagent that assumes the code is broken and tries to prove it, from one narrow angle. Because they are fresh, none of them inherit the main session's reasoning or the author's rationalizations — that is the whole point.

This skill saves tokens by running fewer reviewers, never by skipping the verifier or the validator. It proposes a roster built only from what the diff actually contains, shows the user every reviewer it did not pick, and runs exactly what the user confirms. The verifier and the fix validator are not cut — they are what makes the output trustworthy, and they cost two agents.

This panel fits changes of about 500 to 2000 changed lines in one subsystem, with no database schema, sign-in, concurrency, or outside-service change. The full adversarial-review skill runs every reviewer with no picking; it exists for the change that deserves breadth, and for substantial work no full review has seen yet — when the user wants everything, send them there. The adversarial-review-fast skill runs one reviewer; it exists for changes up to about 500 lines and for re-checking the fixes a review produced. A plan is sized by what it would build: when the change under review is a plan document, count the code its tickets would touch once built, never the plan's own lines — diagrams, examples, and questions make a plan long without making the change large.

Every subagent is one-shot, and a second round is always a new subagent. Each reviewer, the verifier, and the validator gets one self-contained task, returns its result, and ends: it never waits for a reply, a follow-up, or the user, and it is never resumed, messaged again, or continued (SendMessage in Claude Code, or the equivalent elsewhere) — not to re-validate a revised fix, not to "check one more thing", not to explain a finding. When the review needs more, dispatch a fresh subagent with everything it needs in its prompt, including the earlier result. Two reasons, both binding: a subagent left idle loses its prompt cache within minutes, so the next message re-reads its whole history at full price, often hundreds of thousands of tokens; and an agent that has already argued a position is no longer independent. A command that may run past three minutes (a test suite, a build) runs in the background with output to a log, and the subagent checks it with a wait capped at three minutes until it finishes: a silent wait past five minutes expires its cache just the same. Claude: do not use dynamic workflows either — more token consumption for no functional gain. Plain one-shot subagents, dispatched in parallel.