adversarial-review

name	adversarial-review
description	Use when reviewing code changes adversarially. Three-layer review with information asymmetry — Blind Hunter (diff only), Edge Case Hunter (diff + code access), Acceptance Auditor (diff + spec). Required for the Blind Hunter / Edge Case Hunter / Acceptance Auditor agents and invoked transitively by the orchestrator when dispatching reviewers.

Adversarial Review

Your job: find what's wrong with this code change. Not what's right. Zero findings is a red flag — re-examine before claiming clean.

The Three Layers

In the AoE-orchestrated flow, each layer is a separate sub-agent session with its own persona file (blind-hunter.md, edge-case-hunter.md, acceptance-auditor.md). Running the three in parallel sessions preserves the information asymmetry that makes this review useful — if one agent sees the spec, they can't "un-see" it when playing Blind Hunter.

When running without AoE, a single session can still execute all three layers sequentially; just be disciplined about closing the context between layers.

Each layer has deliberately limited context to surface different classes of issues.

Layer 1: Blind Hunter

Inputs: the diff, nothing else.

Mindset: You are reviewing code with no context, no spec, no project knowledge. You see only what changed.

What this catches:

• Code that doesn't make sense on its own (broken logic visible from the diff)
• Obvious errors (typos, wrong operators, off-by-one)
• Code smells (functions that do too much, magic numbers, unsafe patterns)
• Security red flags (string concatenation in queries, hardcoded secrets, missing input validation)

Output format:

### Blind Hunter Findings

**B-01** [severity] Title
- Location: file:line
- Issue: what's wrong
- Evidence: relevant code excerpt

Layer 2: Edge Case Hunter

Inputs: the diff + read access to the project (no spec).

Mindset: You know the codebase but not what was supposed to be built. You hunt for edge cases the implementer missed.

What this catches:

• Null/undefined handling gaps
• Empty input cases (empty arrays, empty strings, zero counts)
• Boundary conditions (min/max values, integer overflow, off-by-one)
• Concurrent access issues
• Error path failures (what happens when this throws?)
• Integration mismatches with existing code (the implementer's new code doesn't match conventions used elsewhere)
• Missing tests for edge cases

Output format: same as Blind Hunter, prefix with E-XX.

Layer 3: Acceptance Auditor

Inputs: the diff + the spec (PLAN.md task section) + read access to the project.

Mindset: You know exactly what was supposed to be built. You verify the diff delivers it.

What this catches:

• Acceptance criteria not met
• Constraints violated
• Files modified outside touches_files
• Functionality that exists but is incomplete (placeholder values, "TODO" comments, stub implementations)
• Feature creep (added stuff not in the spec)

Output format: same as above, prefix with A-XX.

Severity Classification

Severity	When to use
CRITICAL	Security vulnerability, data corruption risk, broken core functionality, missing required AC
HIGH	Wrong behavior in common cases, missing error handling, broken integration, missing test for critical path
MEDIUM	Edge case not handled, missing test for non-critical path, code smell that will cause future bugs
LOW	Style inconsistency, minor refactor opportunity, missing comment for non-obvious code

Triage Protocol

After collecting findings from all layers, classify each into one of:

Bucket	Meaning	Action
patch	Trivial fix, no spec change needed	Implementer applies fix
bad_spec	Issue caused by ambiguous/wrong spec	Replan task with finding as input
intent_gap	Spec doesn't cover this case at all	HALT, ask user for decision
defer	Pre-existing issue, not caused by this change	Add to deferred-issues.md
reject	Noise, false positive, opinion	Drop

The Zero-Findings Trap

If you find nothing, re-examine before declaring clean:

1. Did you actually read the diff or just skim?
2. Are you defaulting to "looks reasonable" because the code is well-formatted?
3. Is there really no edge case the implementer missed?

If after honest re-examination you still find nothing, write:

## No Findings

After careful review of:
- [list what you reviewed]
- [list what edge cases you considered]
- [list which AC you verified]

I have no findings to report. The diff appears to fully implement the spec without obvious bugs, security issues, or missed edge cases.

This forces honesty. Don't write "looks good" without explaining what you actually checked.

Anti-patterns

• Performative criticism: making up issues to look thorough — better to explain what you actually checked
• "This could be improved by...": review evaluates correctness, not aesthetic preferences
• Bikeshedding on naming or formatting: only call out if it's actually wrong (e.g., violates project conventions)
• Reviewing the spec instead of the diff: if the spec is wrong, classify as bad_spec, don't lecture the implementer about it

Output Structure

# Review: <task-id>

## Summary
- Layers run: Blind / Edge / Acceptance
- Findings: <N> total (<X> critical, <Y> high, <Z> medium, <W> low)
- Verdict: APPROVED / CHANGES_REQUESTED / REJECTED

## Findings

[All findings with full classification]

## Triage

| Finding | Bucket | Owner |
|---|---|---|
| B-01 | patch | implementer |
| E-03 | bad_spec | planner |
| A-02 | intent_gap | user |