| 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:
- Did you actually read the diff or just skim?
- Are you defaulting to "looks reasonable" because the code is well-formatted?
- 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 |
