Adversarial Review

Adversarial Review (GAN Loop)

Overview

A persistent adversarial loop between two agents: an Implementer (Sonnet) that produces output, and a Challenger (Sonnet) that critiques it. The loop drives iterative improvement through structured verdicts until the output is excellent.

Core principle: The challenger IS the quality gate. Nothing returns to the user until the challenger says PASS.

When to Use

• Complex, multi-faceted tasks where a second pair of eyes catches real issues
• Tasks where correctness matters: algorithms, parsers, data pipelines, auth logic
• Design + implementation tasks where blind spots are likely

When NOT to use:

• Trivial one-liners or single-function tasks with no room for error
• Tasks the user needs immediately (this is slow — 2+ rounds minimum)
• Purely conversational/informational requests

Flow

1. Spawn Implementer (Sonnet) with the task
2. Spawn Challenger (Sonnet) with the Implementer's initial output
3. Loop until exit condition:

digraph gan_loop {
    rankdir=LR;

    "User: task" [shape=doublecircle];
    "Spawn Implementer\n(model: sonnet)" [shape=box];
    "Spawn Challenger" [shape=box];
    "Implementer produces\nor revises output" [shape=box];
    "Challenger reviews\n→ PASS/FAIL +\nSUMMARY + FEEDBACK" [shape=box];
    "PASS?" [shape=diamond];
    "Return final output\nto user" [shape=doublecircle];
    "SendMessage to\nImplementer with FEEDBACK" [shape=box];
    "Compact challenger\ncontext (append round\nsummary, drop old output)" [shape=box];
    "Max rounds (10)\nor stalemate?" [shape=diamond];
    "Return best output +\nwarning to user" [shape=doublecircle];

    "User: task" -> "Spawn Implementer\n(model: sonnet)";
    "Spawn Implementer\n(model: sonnet)" -> "Implementer produces\nor revises output";
    "Implementer produces\nor revises output" -> "Spawn Challenger";
    "Spawn Challenger" -> "Challenger reviews\n→ PASS/FAIL +\nSUMMARY + FEEDBACK";
    "Challenger reviews\n→ PASS/FAIL +\nSUMMARY + FEEDBACK" -> "PASS?";
    "PASS?" -> "Return final output\nto user" [label="PASS"];
    "PASS?" -> "Max rounds (10)\nor stalemate?" [label="FAIL"];
    "Max rounds (10)\nor stalemate?" -> "Return best output +\nwarning to user" [label="yes"];
    "Max rounds (10)\nor stalemate?" -> "SendMessage to\nImplementer with FEEDBACK" [label="no"];
    "SendMessage to\nImplementer with FEEDBACK" -> "Compact challenger\ncontext (append round\nsummary, drop old output)";
    "Compact challenger\ncontext (append round\nsummary, drop old output)" -> "Implementer produces\nor revises output";
}

Agent Templates

Implementer (spawn once, model: sonnet)

Spawn with the Agent tool: model: "sonnet", name: "implementer".

You are a skilled implementer. Produce high-quality output for the given task.

## Task
{user_task}

## Rules
1. Produce thorough, correct, well-structured output
2. When you receive FEEDBACK from the challenger, revise your output to address every point
3. Do NOT argue with feedback — incorporate it constructively
4. You may receive multiple rounds of feedback — keep improving each round
5. If you genuinely believe a piece of feedback is incorrect, explain why briefly and offer an alternative
6. Output ONLY the revised work, not meta-commentary about the process

Challenger (spawn once, model: Sonnet)

Spawn with the Agent tool: model: Sonnet, name: "challenger".

You are a rigorous challenger. Your job is to find every flaw in the output — bugs, logic errors, missing edge cases, security issues, design problems, unclear code, performance issues, and missing error handling.

## Output Format (STRICT — you MUST follow this exactly)

You MUST output exactly the following structure. The orchestrator parses it; if you deviate, the loop breaks.

VERDICT: PASS|FAIL
SUMMARY: <2-3 line summary of what was reviewed and your overall assessment>
FEEDBACK: <specific, actionable critique — only if FAIL>

## Verdict Rules

- PASS: the output is excellent. No bugs, no missing edge cases, no design issues, no security concerns. It is production-ready.
- FAIL: anything less than excellent. Every bug, gap, or improvement goes in FEEDBACK.

## Feedback Guidelines

- Be specific: cite line numbers, exact bugs, missing cases
- Be actionable: say HOW to fix, not just what's wrong
- Be thorough: check correctness, edge cases, error handling, security, design, readability
- Do NOT: nitpick trivial formatting, comment on style preferences, or make vague suggestions
- Write the SUMMARY as if it will be the ONLY record of this round in future context — it must capture what was produced, what was wrong, and what changed

Round Mechanics

Each round after the initial:

1. Challenger reviews the Implementer's latest output → produces verdict
2. Orchestrator (you) parses the verdict:
   • Extract VERDICT: line → PASS or FAIL
   • Extract SUMMARY: line(s) → save for compaction
   • Extract FEEDBACK: content → save for relaying
3. If PASS: return the Implementer's latest output to the user. Done.
4. If FAIL:
   • SendMessage to the Implementer with: "Challenger feedback (Round N):\n{FEEDBACK}\n\nRevise your output to address all points above."
   • Wait for the Implementer's revised output
   • SendMessage to the Challenger with compacted context (see below)

Context Compaction (Critical)

Without compaction, the challenger's context grows unbounded. After each round, SendMessage to the challenger with a compact representation:

Round N review:

=== PAST ROUNDS ===
Round 1: [SUMMARY from round 1]
Round 2: [SUMMARY from round 2]
...
Round N-1: [SUMMARY from round N-1]

=== CURRENT ROUND (N) ===
[Implementer's full revised output]

The orchestrator (you) maintains the list of past round summaries. After each round, append the new summary. The challenger sees: all past summaries + the full current output. This preserves adversarial memory without the bloat.

Never skip compaction. After 5 rounds without compaction, the challenger's context is >50k tokens of stale output.

Exit Conditions

Safety Rails

• Max 10 rounds — enforced by counting rounds; stop at 10 regardless
• Stalemate detection — compare FEEDBACK string to previous round; if identical, stop
• Both agents persist — spawn ONCE each, all subsequent communication via SendMessage. Never re-spawn mid-loop
• Model enforcement — Implementer MUST use model: "sonnet". Challenger inherits session model
• Budget awareness — warn the user upfront: "Running GAN loop — this will spawn 2 persistent agents and may use significant tokens across up to 10 rounds." Proceed only if the task warrants it
• Challenger fatigue guard — if the challenger issues PASS before round 2, challenge it: "Are you sure? Review again — this is only round N." Early PASS is usually leniency, not genuine approval
• Feedback-addressing check — the challenger MUST verify whether its PREVIOUS feedback was actually addressed. If the implementer ignored a critique, call it out explicitly: "Still not addressed: [issue]"

Agent Death Recovery

If an agent dies (unreachable via SendMessage, agent not found):

• Implementer dies: Re-spawn with model: "sonnet", name: "implementer". Share the task + all past challenger feedback so it can catch up. Continue the loop with the new agent_id.
• Challenger dies: Re-spawn with name: "challenger". Share the current implementer output + past round summaries so it can continue. Continue the loop with the new agent_id.
• Both die: Re-spawn both. Start the loop from scratch with the original task. Treat this as a new loop (round counter resets).

Common Mistakes

Red Flags — STOP and Fix

• "This is simple, I'll just review it myself" → You are not the challenger. Spawn it.
• "The implementer's output looks good enough" → The challenger decides that, not you.
• "I'll just do one challenge round" → The loop runs until PASS. One round is not enough.
• "Challenger is taking too long" → Quality takes time and tokens. That's why this skill is explicit-invoke only.
• Using a fresh challenger agent instead of SendMessage → Wrong. It must persist to build adversarial knowledge.
• Skipping compaction because "context isn't that big yet" → Context grows fast. Compact from round 1.

Rationalization Table