insight-adversarial
Skill15 starsChanged 15 days agoApache-2.0View on GitHub
Multi-pass adversarial critique from dynamically selected personas — including the current reviewer's own view. 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 3–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.
In this repository95 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- agent-mailboxSkill
- agent-outputSkill
- ask-gateSkill
- ask-meSkill
- audit-coupled-constantSkill
- budget-checkSkill
- build-prototypeSkill
- caller-optionsSkill
- cold-reviewSkill
- debug-taskSkill
- define-termsSkill
- defuddleSkill
- design-an-interfaceSkill
- diff-recapSkill
- directives-auditSkill
- domain-checkSkill
- double-checkSkill
- extract-signalSkill
- freshness-contractSkill
- github-syncSkill
- handoff-executeSkill
- handoffSkill
- headless-claudeSkill
- headless-codexSkill
- headless-geminiSkill
- headless-grokSkill
- headless-modelsSkill
- headless-update-modelsSkill
- headless-usageSkill
- human-drawSkill
- human-mergeSkill
- human-outputSkill
- human-rewriteSkill
- implement-taskSkill
- improve-codebase-architectureSkill
- insight-anglesSkill
- insight-assessSkill
- insight-critiqueSkill
- insight-cross-examineSkill
- insight-exploreSkill
- insight-premortemSkill
- insight-reference-classSkill
- insight-retroSkill
- insight-root-causeSkill
- insight-skill-gapSkill
- insight-test-assumptionSkill
- insight-value-of-informationSkill
- investigateSkill
- json-canvasSkill
- map-checkSkill
- map-initSkill
- map-maintainSkill
- map-rulesSkill
- map-thisSkill
- monorepo-depsSkill
- multi-agent-modeSkill
- next-skillsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 11 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 61
Before selecting personas, classify the target:
- Distinctive: line 80
Always include Current Reviewer's Own View as the final persona in every pass
- Distinctive: line 111
Pass 1 or 2: Ask user if they want another pass.
- Very specific: line 112
Pass 3: Check if all Critical Issues resolved or explicitly accepted.
- Distinctive: line 116
MUST classify target type before selecting personas
- Distinctive: line 117
MUST select minimum 4 personas per pass (including Current Reviewer's Own View)
- Distinctive: line 118
MUST include Current Reviewer's Own View in every pass, always last
- Distinctive: line 119
MUST NOT reuse a substantive critic persona across passes.
- Distinctive: line 120
MUST NOT offer solutions inside a persona pass — remediation belongs in Step 4 only
- Distinctive: line 121
MUST NOT soften findings to be diplomatic
- Distinctive: line 122
SHOULD add 3–4 genuinely new personas on Pass 2
- Distinctive: line 123
SHOULD tailor persona selection to target type
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/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@STAMPdate.
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 3–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 substantive critic personas; Current Reviewer's Own View recurs in every pass.
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 Current Reviewer's Own View as the final persona in every pass
- Never reuse a substantive critic persona across passes; Current Reviewer's Own View is exempt — track used personas explicitly
Step 3 — Run Each Persona Pass
For each selected persona:
- State the persona name and their lens in one sentence
- Report specific, evidenced findings. If none are supported, say no material finding supported in the inspected scope, naming that scope and remaining uncertainty. Never invent an issue to fill the format.
- Merge convergent findings across personas, retaining their evidence; do not invent differences to make each lens unique.
Format:
## 🔴 [PERSONA NAME]
*Lens: [one-sentence description]*
[Critique — specific, no softening]Current Reviewer's Own View always goes last. First person, clear position, no hedging.
Step 4 — Synthesis
- Critical Issues — up to 3 supported issues, ranked by actual severity; label lower severities honestly and say when no critical issue is supported. A sound target may have no material finding.
- 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 Current Reviewer's Own View)
- MUST include Current Reviewer's Own View in every pass, always last
- MUST NOT reuse a substantive critic persona across passes; Current Reviewer's Own View is exempt
- MUST NOT offer solutions inside a persona pass — remediation belongs in Step 4 only
- MUST NOT soften findings to be diplomatic
- SHOULD add 3–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 thenext-skillsrecommendations 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): apply its signal taxonomy and threshold to this run; surface any surviving proposal for handler approval. Conservative — silent otherwise. Never auto-apply.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

