Adversarial Review

SKILL.md

---
name: adversarial-review
description: "Run a structured adversarial multi-agent review loop on any significant document. Spawns parallel Opus reviewers with different critical lenses, collects structured redlines, then guides farsight through agree/disagree positioning and v2 production. SELF-TRIGGERING: load this skill and run the complexity self-assessment whenever you are about to produce or have just produced any substantial document — score it and offer the review loop if it qualifies. Also load when the user says things like: 'use the review team', 'get the review team on this', 'spin up the reviewers', 'have the team look at this', 'red-team this', 'redline this', 'challenge this', 'critique this', 'tear this apart', 'poke holes in this', 'stress test this', 'pressure test this', 'sanity check this', 'validate this', 'get a second opinion', 'before we build/implement/ship this'."
---

# Adversarial Review

Structured multi-agent review loop. Catches what a single agent misses.

**Session store:** `~/.openclaw/workspace/reviews/`  
**Process:** Init session → spawn Opus reviewers → collect redlines → position on each → produce v2 → deliver

---

## Complexity Self-Assessment

**Run this check whenever you produce a substantial document.** Score 1 point per signal present. If score ≥ 3, offer the review loop without being asked.

| # | Signal | Points |
|---|--------|--------|
| 1 | Has multiple interdependent components (failure in one affects others) | 1 |
| 2 | Involves schema changes, migrations, or index design | 1 |
| 3 | Irreversible or expensive to undo (data loss, structural rework) | 1 |
| 4 | Affects production systems, stored data, or external services | 1 |
| 5 | Introduces new abstractions, taxonomies, or data models | 1 |
| 6 | Has a defined sequence of steps where order matters | 1 |
| 7 | Contains security, access control, or permission logic | 1 |
| 8 | Will be acted on by code or agents without further human review | 1 |
| 9 | Document is longer than ~500 lines or covers 3+ distinct systems | 1 |
| 10 | Scott said "let's build this" or "implement this" at any point in the conversation | 1 |

**Score 0–2 → skip.** Simple doc, don't add noise.

**Score 3–6 → offer.** *"This scores [N]/10 on complexity. Want me to run the review team on it before we act?"*

**Score 7–10 → strongly recommend.** Don't just offer — make the case. *"This scores [N]/10 on complexity — multiple interdependent systems, production consequences, hard to reverse. I'd strongly recommend running the review team before we act on this. Today's taxonomy strategy was a 10/10 and the review caught 14 issues including multiple production-breaking bugs."*

---

## Quick Reference

| Step | Action |
|------|--------|
| 0. Init session | `scripts/new-review.sh <slug> <path-to-doc>` |
| 1. Choose reviewers | Read `references/review-types.md` for the right bundle |
| 2. Spawn reviewers | `sessions_spawn` with `model=anthropic/claude-opus-4-6`, `mode=run` — all in parallel |
| 3. Wait | Reviewers auto-announce. Do NOT poll. |
| 4. Save raw output | Write each reviewer result to `redlines/reviewer-{role}.md` |
| 5. Synthesize | `scripts/synthesize.sh <session-dir>` → writes `redlines/combined.md` |
| 6. Position | AGREE / DISAGREE / MODIFY on every redline → write `positions.md` |
| 7. Produce v2 | Write `output/{slug}-v2.md` incorporating accepted changes + rejected appendix |
| 8. Deliver | `scripts/cp-output.sh <session-name> <destination>` |

---

## Session Directory Structure

```
~/.openclaw/workspace/reviews/{YYYY-MM-DD}-{slug}/
├── input/
│   └── {original-filename}       ← copy of doc being reviewed
├── redlines/
│   ├── reviewer-{role}.md        ← raw output per reviewer
│   └── combined.md               ← synthesize.sh output (sorted by severity)
├── positions.md                  ← farsight agree/disagree log
└── output/
    └── {slug}-v2.md              ← final document
```

---

## Review Types

| Document Type | Reviewer A | Reviewer B |
|---------------|-----------|-----------|
| Architecture / strategy | Theory & data modeling | Implementation & systems |
| Pipeline / workflow | Sequencing & dependencies | Failure modes & ops |
| Schema / migration | SQL correctness & constraints | Performance & indexes |
| Security design | Threat modeling | Implementation gaps |
| Marketing / positioning | Message clarity & truth | Competitive exposure |
| API / interface design | Consistency & contracts | Consumer experience |

For full persona prompt templates → read `references/reviewer-personas.md`  
For pre-configured bundles → read `references/review-types.md`

---

## Spawning Reviewers

Spawn ALL reviewers simultaneously — parallel, not sequential. Independent reviewers find different issues.

### Model Selection

| Doc Score | Default Model | Rationale |
|-----------|--------------|-----------|
| 7–10 | `anthropic/claude-opus-4-6` | Deep reasoning required; subtle architectural flaws need Opus |
| 3–6 | `anthropic/claude-sonnet-4-6` | Worth trying; structured prompts may close the gap |

**A/B testing note:** If Sonnet misses a CRITICAL issue that Opus would have caught on a 3–6 doc, upgrade that doc type to Opus permanently. Track findings in `references/model-notes.md` as patterns emerge.

Key parameters for every reviewer spawn:
```
model: anthropic/claude-opus-4-6   ← or sonnet for 3-6 scored docs
mode: run
runTimeoutSeconds: 300
label: reviewer-{role}
```

The task field contains the full reviewer prompt from `references/reviewer-personas.md` plus the document content to review.

---

## Positioning Rules

For EVERY redline, take an explicit position. No skipping.

| Position | When | Requirement |
|----------|------|------------|
| **AGREE** | Critique is correct, change should be made | State what changes |
| **DISAGREE** | Original design is defensible | Must provide rationale — not just dismissal |
| **MODIFY** | Issue is real, suggested resolution is wrong | Propose your alternative |

All CRITICAL redlines default to AGREE unless strongly defensible.  
At least 1 DISAGREE expected — if zero, you may be rubber-stamping.

Write positions to `positions.md` in the session directory.

---

## v2 Requirements

- Revision table at the top (what changed and why)
- All AGREE + MODIFY changes incorporated
- Rejected redlines documented in an appendix ("considered and rejected")
- Version bumped, date updated
- Saved to `output/{slug}-v2.md`

---

## Quality Bar

A good review session produces:
- ≥2 CRITICAL issues (if zero, reviewers weren't adversarial enough — re-spawn with harder prompt)
- ≥1 DISAGREE from farsight (if zero, consider whether the doc was genuinely perfect or just unchallenged)
- A v2 meaningfully different from v1

---

## Redline Format

```
**[REDLINE-{TYPE}-{NNN}]** {Section reference}
**Claim:** What the document says
**Challenge:** The specific objection or gap
**Severity:** CRITICAL | MAJOR | MINOR
**Suggested Resolution:** What should change
```

Full spec → read `references/redline-format.md`