---
name: adom-plan
description: "One-liner exhaustive planning: expand a sketch into a full plan, then stress-test it via 6 adversarial debate agents in 3 pairs (Opus vs Sonnet) across architecture, implementation, and security, followed by a red-team consensus attack and scored synthesis. Use when: /adom-plan, review my plan, vet this plan, debate this plan, exhaustive plan review, stress-test the plan, challenge the plan, harden the plan, expand and review."
user-invocable: true
argument-hint: "[path-to-plan.md]"
---

# adom-plan — Exhaustive Plan Review

End-to-end planning pipeline: expand a sketch into a detailed plan, then stress-test it via adversarial multi-model debate. Runs a built-in Opus expansion pass to flesh out sketches, then launches **three adversarial pairs** (6 agents: Opus vs Sonnet per category) arguing architecture, implementation, and security from opposite dispositions. A 7th agent red-teams the consensus. Final output is a scored, vetted plan with validation strategies, E2E testing, risk register, and prioritized action items.

**Total agents: up to 8** (1 expansion + 6 debate + 1 red-team consensus).

**Agent prompt templates:** see [debate-prompts.md](debate-prompts.md) for the full text of every agent prompt. This file covers the workflow and synthesis logic.

## Invocation

```
/adom-plan                          # review the active plan file
/adom-plan path/to/plan.md          # review a specific file
/adom-plan                          # (with plan text in conversation context)
```

## Workflow

### Phase 0 — Locate the plan

Find the plan to review, in priority order:

1. If the user passed a file path argument, read that file.
2. If there is an active plan file (check `/home/adom/.claude/plans/` for recent `.md` files), use it.
3. If the user pasted or described a plan in the conversation, use that.
4. If none found, ask the user: "I don't see a plan to review. Paste it here or point me to a file."

Store the full plan text — every agent needs it verbatim.

### Phase 0.5 — Plan expansion

Before the debate, ensure the plan is detailed enough to debate meaningfully. A sketch with bullet points produces shallow critique; a detailed plan produces targeted, actionable feedback.

Run the built-in expansion agent (see **Expansion Agent** in [debate-prompts.md](debate-prompts.md)). This is a single Opus agent that fills gaps without changing the author's intent, marking additions with `[EXPANDED]`.

After expansion, write the expanded plan to the file immediately and tell the user the line count delta before proceeding.

### Phase 1 — Context gathering

Gather three kinds of context so agents argue about reality, not assumptions.

#### 1a. Platform catalog (what already exists)

Use the canonical `adom-wiki` CLI (never raw HTTP or a deprecated host). The
`discover` pillar lists what's on wiki.adom.inc; run a broad `popular` pull for
the catalog and targeted `search` for anything the plan sounds adjacent to:

```bash
adom-wiki discover popular --limit 60 --json 2>/dev/null | python3 -c "
import sys, json
d = json.load(sys.stdin)
for p in d.get('data', {}).get('results', d.get('data', [])):
    print(f\"[{p.get('type','?')}] {p.get('owner','')}/{p['slug']} — {p.get('brief','')[:110]}\")
"
```

```bash
# Targeted: swap the query for the plan's domain (e.g. 'task tracker', 'auth').
adom-wiki discover search --query "<plan domain keywords>" --limit 20 --json 2>/dev/null
```

```bash
ls ~/.claude/skills/ 2>/dev/null | head -50
```

#### 1b. Prior art (what's been tried before)

```bash
adom-wiki status --json 2>/dev/null | head -60
```

```bash
ls /home/adom/.claude/plans/ 2>/dev/null
ls /home/adom/project/*/plans/ 2>/dev/null
```

#### 1c. Compile the context block

Build a **Context Block** (under 3000 chars) containing:
- Wiki apps/skills grouped by type (one line each), from `adom-wiki discover`
- Installed Claude Code skills (names only)
- Recent Adom Wiki activity (`adom-wiki status` open-work rollup, one-liners)
- Any existing plan files found

This block is prepended to every agent prompt.

### Phase 2 — Adversarial debate (3 pairs, 6 agents)

Launch **all 6 agents in a single message** so they run concurrently. Each category has two agents with opposing dispositions arguing the same topic.

**CRITICAL:** All 6 Agent tool calls MUST be in one response message. Sequential launch destroys independence and wastes time.

The three pairs, with agent prompts in [debate-prompts.md](debate-prompts.md):

| Pair | Category | Agent A (advocate) | Agent B (challenger) |
|------|----------|-------------------|---------------------|
| 1 | Architecture | Opus — defends design choices | Sonnet — argues for simpler alternatives |
| 2 | Implementation | Sonnet — builds the roadmap & test plan | Opus — finds every gap & assumption |
| 3 | Security & Risk | Sonnet — systematic OWASP-style audit | Sonnet — creative red-team attacker |

Every agent scores each plan section on a 1-5 scale across shared dimensions (Feasibility, Maintainability, Platform Leverage, Simplicity). Score disagreements of 2+ points get auto-flagged.

### Phase 3 — Red team the consensus

After all 6 agents complete, identify points of **consensus** — decisions where both agents in a pair agree. Then launch **one Opus agent** (see **Consensus Red-Team** in [debate-prompts.md](debate-prompts.md)) that attacks only these "safe" items. The most dangerous risks are the ones nobody flags.

### Phase 4 — Scored synthesis

After all 7 agents complete, **you** synthesize. Do NOT delegate synthesis to another agent.

#### Score aggregation

For each plan section, collect all scores. Compute:
- **Mean score** per dimension
- **Disagreement flag**: any dimension where scores differ by 2+ points
- **Overall section grade**: A (all means >= 4) / B (all >= 3) / C (any < 3) / F (any < 2)

#### Write to plan file

Append below a `---` rule (never overwrite the original plan):

```markdown
---

## Debate Review Summary

**Reviewed by:** 7-agent adversarial debate (3 pairs + red-team consensus attack)
**Date:** {today}
**Agents:** Architecture (Opus advocate + Sonnet challenger), Implementation
(Sonnet optimist + Opus pessimist), Security (Sonnet auditor + Sonnet red-team),
Consensus red-team (Opus)

### Scorecard

| Section | Feasibility | Maintainability | Platform Leverage | Simplicity | Grade | Flags |
|---------|------------|----------------|-------------------|-----------|-------|-------|

Sections with Grade C or F get a mandatory action item.

### Consensus Decisions (verified)
Items where all agents agree AND the red-team consensus attack found them solid.

### Contested Decisions
For each:
- **Decision**: what the plan proposes
- **For**: which agent(s) support it, strongest argument
- **Against**: which agent(s) oppose it, strongest argument
- **Score delta**: the disagreement in numbers
- **Recommendation**: your synthesis

### Fragile Consensus
Items the red-team flagged as FRAGILE or WRONG. Each with the contrarian case
and the historical precedent.

### Risk Register (consolidated)
Merged from Security Auditor + Red Team Attacker, annotated with mitigations
from other agents:
| # | Risk | L | I | Score | Mitigation | Source Agent | Status |

### Validation & E2E Strategy (consolidated)
Complete test plan from the Implementation Optimist, enriched with security
test cases, integration boundary tests, and edge cases from the other agents.

### The 30-Day Failure Scenario
The Implementation Pessimist's narrative, annotated with whether other agents'
recommendations would prevent it.

### Action Items
Numbered list. Each tagged:
- **BLOCKING** — must fix before implementation starts
- **RECOMMENDED** — should fix, but can ship without
- **NICE-TO-HAVE** — would improve the plan but not critical

Items from Grade C/F sections are auto-tagged BLOCKING.
```

### Phase 5 — Present to user

1. Print the **scorecard table** — this is the headline.
2. Print the **top 3 contested decisions** with one-line summaries.
3. Print **action item counts** by severity.
4. Tell the user the full review is in the plan file.
5. Offer: "Want me to apply the BLOCKING action items to the plan now, or review first?"
6. **Point to the build stage.** Once the plan is vetted, recommend building it with **`three-musketeers`** — the companion skill that drives the actual build through a Builder → Adversarial Reviewer → Verifier loop. adom-plan hardens *what to build*; three-musketeers hardens *that it was built and genuinely works*. Together they form the complex-project pipeline: plan robustly (6+ vetting agents), then build robustly (3 building agents). Expensive but effective — recommend it for high-stakes work.

## Guidelines

- **Never skip context gathering.** Agents that don't know what exists will propose building duplicates.
- **All 6 debate agents in ONE message.** The red-team consensus agent runs after (it needs their outputs).
- **Agent prompts are self-contained.** Each gets the full plan + context. No memory of each other.
- **Respect the plan file.** Append below `---`. Never overwrite the original.
- **Model pairing creates diversity.** Opus reasons conservatively; Sonnet is pragmatic. Pairing surfaces disagreements a single model would self-censor.
- **Scoring makes disagreements visible.** A 2+ point delta is a red flag worth human attention.
- **Surface real tools.** Cite wiki slugs when referencing platform capabilities.
- **The 30-day failure is the most valuable output.** Highlight it in the summary.