/insight-adversarial
Structured adversarial review that assembles a panel of distinct critic personas, runs each through a focused pass, and synthesizes a verdict. Personas are selected based on the nature of the target — a YON workflow gets different critics than a business plan or a UX design.
Structured execution spec: protocol.yon. Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the @STAMP date.
Caller Options. Before executing, run the Caller Options protocol (caller-options/SKILL.md): triage this invocation for material optionality across the venues and modes declared in front-matter; if one path clearly dominates, proceed silently; otherwise surface the options to the caller. A resolved-invocation marker means COP already ran — execute the fixed combination directly, do not re-enter COP.
How Passes Work
| Pass |
What Happens |
| Pass 1 |
Classify the target → select 4–5 personas → run each → synthesize verdict |
| Pass 2 |
Check against Pass 1 findings → add 2–4 new personas not used before → re-run → delta verdict |
| Pass 3 |
Final wrap-up. If all critical issues resolved or within params, declare done. Otherwise escalate. |
State tracking: at the top of each pass, list which personas were used in prior passes. New passes must not reuse them.
Step 1 — Target Classification
Before selecting personas, classify the target:
| Target Type |
Key Question |
Primary Risk |
plan |
Is this executable? |
Scope drift, undeclared deps |
design / architecture |
Does structure match intent? |
Coupling, ownership violations |
yon-workflow |
Does this execute correctly end-to-end? |
Gate logic, step ordering, missing catches |
document / spec |
Is this complete and unambiguous? |
Gaps, contradictions, assumed context |
idea / concept |
Is the core premise sound? |
Wrong problem, premature solution |
business / product |
Is this viable and desirable? |
Market assumptions, cost blindness |
code / implementation |
Is this correct and maintainable? |
Edge cases, coupling, test coverage |
ui / ux |
Will real users succeed with this? |
Flow breakdowns, mental model gaps |
Load personas/roster.md to see all available personas and their best-used-for tags. Use the classification to select the most relevant 4–5 personas for this pass.
Step 2 — Persona Selection Logic
- Pick the primary persona — whose domain most directly overlaps the target's failure mode
- Pick 2–3 supporting personas — different angles that complement, not duplicate, primary
- Always include Claude's Own POV as the final persona in every pass
- Never reuse a persona across passes — track used personas explicitly
Step 3 — Run Each Persona Pass
For each selected persona:
- State the persona name and their lens in one sentence
- Run critique — at least one specific, named finding — no generalities
- Findings must be distinct across personas in this pass
Format:
## 🔴 [PERSONA NAME]
*Lens: [one-sentence description]*
[Critique — specific, no softening]
Claude's Own POV always goes last. First person, clear position, no hedging.
Step 4 — Synthesis
- Critical Issues — top 3, ranked by severity
- Blind Spots — what the aggregate reveals that no single persona fully caught
- Remediation — minimum surgical fix per Critical Issue. If unfixable, say so.
- One-Line Verdict — honest, specific, no hedging
Step 5 — Pass Wrap Logic
- Pass 1 or 2: Ask user if they want another pass. If yes → load new personas, run delta critique focused on unresolved issues.
- Pass 3: Check if all Critical Issues resolved or explicitly accepted. If yes → final consolidated verdict + declare wrap. If no → flag remaining open issues, recommend escalation (e.g.,
/plan-create).
Rules
- MUST classify target type before selecting personas
- MUST select minimum 4 personas per pass (including Claude's Own POV)
- MUST include Claude's Own POV in every pass, always last
- MUST NOT reuse a persona across passes
- MUST NOT offer solutions inside a persona pass — remediation belongs in Step 4 only
- MUST NOT soften findings to be diplomatic
- SHOULD add 2–4 genuinely new personas on Pass 2
- SHOULD tailor persona selection to target type
- MAY suppress a persona if user explicitly requests it
Files
- personas/roster.md — Full persona library. Load during Step 1 to inform selection.
Human output. This skill's handler-facing output obeys the human-output
contract (human-output/SKILL.md).
Next skills. On completion, run the Next Skills protocol (next-skills/SKILL.md): surface the next-skills recommendations from front-matter for the caller to pick. Offer only — never auto-invoke.
Self-improvement. On completion, run the Self-Improvement Protocol (self-improve/SKILL.md): if this run surfaced a concrete, blocking-or-recurring weakness in this skill, propose a specific fix for the handler to approve. Conservative — silent otherwise. Never auto-apply.
1---2name: insight-adversarial3description: Multi-pass adversarial critique from dynamically selected personas — including Claude's own POV. Trigger on: "adversarial", "red team this", "multi-POV review", "stress-test", "poke holes", "what am I missing", "attack my plan", "critique from multiple angles", "is this solid", "what would a skeptic say", or any request for rigorous structured criticism of a plan, design, doc, workflow, YON, idea, or system. Runs 1–3 passes. First pass selects 4+ personas from the roster. Each subsequent pass adds 2–4 new personas to the mix. Third pass wraps with a final verdict if all issues are within acceptable params. Do not skip this skill when the user wants real scrutiny — "just give me feedback" often means they need this.4---56# /insight-adversarial78Structured adversarial review that assembles a panel of distinct critic personas, runs each through a focused pass, and synthesizes a verdict. Personas are selected based on the *nature of the target* — a YON workflow gets different critics than a business plan or a UX design.910> **Structured execution spec:** [`protocol.yon`](protocol.yon). Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the `@STAMP` date.1112> **Caller Options.** Before executing, run the Caller Options protocol (`caller-options/SKILL.md`): triage this invocation for material optionality across the venues and modes declared in front-matter; if one path clearly dominates, proceed silently; otherwise surface the options to the caller. A resolved-invocation marker means COP already ran — execute the fixed combination directly, do not re-enter COP.1314## How Passes Work1516| Pass | What Happens |17|------|-------------|18| **Pass 1** | Classify the target → select 4–5 personas → run each → synthesize verdict |19| **Pass 2** | Check against Pass 1 findings → add 2–4 *new* personas not used before → re-run → delta verdict |20| **Pass 3** | Final wrap-up. If all critical issues resolved or within params, declare done. Otherwise escalate. |2122**State tracking:** at the top of each pass, list which personas were used in prior passes. New passes must not reuse them.2324## Step 1 — Target Classification2526Before selecting personas, classify the target:2728| Target Type | Key Question | Primary Risk |29|-------------|-------------|--------------|30| `plan` | Is this executable? | Scope drift, undeclared deps |31| `design / architecture` | Does structure match intent? | Coupling, ownership violations |32| `yon-workflow` | Does this execute correctly end-to-end? | Gate logic, step ordering, missing catches |33| `document / spec` | Is this complete and unambiguous? | Gaps, contradictions, assumed context |34| `idea / concept` | Is the core premise sound? | Wrong problem, premature solution |35| `business / product` | Is this viable and desirable? | Market assumptions, cost blindness |36| `code / implementation` | Is this correct and maintainable? | Edge cases, coupling, test coverage |37| `ui / ux` | Will real users succeed with this? | Flow breakdowns, mental model gaps |3839Load `personas/roster.md` to see all available personas and their best-used-for tags. Use the classification to select the most relevant 4–5 personas for this pass.4041## Step 2 — Persona Selection Logic42431. Pick the **primary persona** — whose domain most directly overlaps the target's failure mode442. Pick 2–3 **supporting personas** — different angles that complement, not duplicate, primary453. Always include **Claude's Own POV** as the final persona in every pass464. **Never reuse** a persona across passes — track used personas explicitly4748## Step 3 — Run Each Persona Pass4950For each selected persona:51521. State the persona name and their lens in one sentence532. Run critique — **at least one specific, named finding** — no generalities543. Findings must be distinct across personas in this pass5556**Format:**5758```59## 🔴 [PERSONA NAME]60*Lens: [one-sentence description]*6162[Critique — specific, no softening]63```6465Claude's Own POV always goes last. First person, clear position, no hedging.6667## Step 4 — Synthesis6869- **Critical Issues** — top 3, ranked by severity70- **Blind Spots** — what the aggregate reveals that no single persona fully caught71- **Remediation** — minimum surgical fix per Critical Issue. If unfixable, say so.72- **One-Line Verdict** — honest, specific, no hedging7374## Step 5 — Pass Wrap Logic7576- **Pass 1 or 2:** Ask user if they want another pass. If yes → load new personas, run delta critique focused on unresolved issues.77- **Pass 3:** Check if all Critical Issues resolved or explicitly accepted. If yes → final consolidated verdict + declare wrap. If no → flag remaining open issues, recommend escalation (e.g., `/plan-create`).7879## Rules8081- MUST classify target type before selecting personas82- MUST select minimum 4 personas per pass (including Claude's Own POV)83- MUST include Claude's Own POV in every pass, always last84- MUST NOT reuse a persona across passes85- MUST NOT offer solutions inside a persona pass — remediation belongs in Step 4 only86- MUST NOT soften findings to be diplomatic87- SHOULD add 2–4 genuinely new personas on Pass 288- SHOULD tailor persona selection to target type89- MAY suppress a persona if user explicitly requests it9091## Files9293- [personas/roster.md](personas/roster.md) — Full persona library. Load during Step 1 to inform selection.9495> **Human output.** This skill's handler-facing output obeys the human-output96> contract (`human-output/SKILL.md`).9798> **Next skills.** On completion, run the Next Skills protocol (`next-skills/SKILL.md`): surface the `next-skills` recommendations from front-matter for the caller to pick. Offer only — never auto-invoke.99100> **Self-improvement.** On completion, run the Self-Improvement Protocol (`self-improve/SKILL.md`): if this run surfaced a concrete, blocking-or-recurring weakness in this skill, propose a specific fix for the handler to approve. Conservative — silent otherwise. Never auto-apply.
allemaar