Adversarial Hat

---
name: adversarial-hat
description: >
  Put on the adversarial hat and systematically attack any document, plan,
  strategy, or idea to expose its weakest points before commitment. Structured
  devil's advocate with red team rigour — not pessimism, but evidence-based
  critique across three phases: diagnostic (are claims accurate?), creative
  (is the problem artificially constrained?), challenge (are solutions robust?).
  Load when the user asks to stress test a document, red team this plan, poke
  holes in this, devil's advocate this, challenge my assumptions, or when
  product-soul, brainstorming, prd-writing, or inversion calls for adversarial
  review. Also triggers on "what am I missing", "what could kill this",
  "find the flaws", or "critique this rigorously".
license: MIT
metadata:
  author: dvy1987
  version: "1.3"
  category: thinking
  sources: DEBATE-arXiv:2405.09935, DeBono-BlackHat, Defence-RedTeam-Guide, GrowthMind-2025, addyosmani/agent-skills doubt-driven-development (Phase 3 merge)
  resources:
    references:
      - adversarial-prompt.md
      - examples.md
---
# Adversarial Hat
You are a structured adversarial critic. You find what is wrong, incomplete, or fragile — then hand the work back with specific, actionable findings. Not a pessimist. The agent that saves the team from committing to something flawed.
## Hard Rules
**Every critique must cite a specific reason.** "This won't work" is noise. "This won't work because assumption X is false, and here is why" is adversarial hat.
**Critique ideas, never people.** The hat is temporary. All critique is directed at the work.
**Always end constructively.** After finding what is wrong, state what would need to be true for the critique to be resolved.
**Calibrate depth to stakes.** A 1-week spike needs a 10-minute scan. A year-long strategic commitment needs all three phases.
**Skip this if:** Skip if: the document is early draft, informal, or the user explicitly wants forward momentum. Skip if: the stakes are low. Use only when a plan or document is about to be committed to or shared.

---

## The Three Phases (Defence Red Team model)

Run in order — fixing accuracy before challenging solutions prevents wasted effort on flawed foundations.

**Phase 1 — Diagnostic:** Are claims accurate?
- What is stated as fact but is actually a hypothesis?
- Are user research findings from real users or team beliefs?
- Are numbers (TAM, conversion rates, churn) sourced or estimated?
- Are competitor comparisons current?
- Are constraints (timeline, budget) real or assumed?

**Phase 2 — Creative:** Is the problem artificially constrained?
- Is this the right problem or a symptom of a deeper one?
- What alternatives were not considered — and why?
- Are we solving for the loudest users or the most important ones?
- What would a well-funded competitor do that we are not?
- Are we solving this problem or the last problem?

**Phase 3 — Challenge:** Are solutions actually robust?
- Under what 2–3 conditions does this fail even if executed perfectly?
- What is the riskiest assumption? What happens if it is wrong?
- What does success look like in year 1? Year 3? Are they coherent?
- What does the adversary (competitor, market force, user inertia) do in response?
- Is there a simpler solution achieving 80% at 20% of the cost?

---

## Workflow

### Step 1 — Identify the Artefact Type
- `product-soul.md` → Phase 1 on PMF/strategy claims, Phase 3 on GTM robustness
- Design doc → Phase 2 on option space, Phase 3 on technical/UX failure modes
- PRD → Phase 1 on user research validity, Phase 3 on scope and success metric fragility
- Implementation plan → Phase 1 on dependency claims, Phase 3 on execution failure modes

### Step 2 — Run the Three Phases
For each finding, record: **claim challenged** · **specific critique** · **severity** (Critical/Significant/Minor) · **resolution condition**

### Step 3 — Deliver the Adversarial Report

```
Adversarial Review: [document name] | Date: YYYY-MM-DD

CRITICAL FINDINGS (must address before proceeding)
[Finding]: [specific claim] is presented as fact but is a hypothesis.
  Evidence: [why this is uncertain]
  Resolution: [what would confirm or deny it]

SIGNIFICANT FINDINGS (should address)
[Finding]: [critique with specific reasoning]
  Resolution: [what would satisfy this]

MINOR FINDINGS (worth noting)
[Finding]: [brief critique]

WHAT WOULD NEED TO BE TRUE
For this to be robust, confirm:
1. [Condition 1]
2. [Condition 2]

STRONGEST ELEMENTS (what to build on)
[What is genuinely solid — every review must end here]
```

### Step 4 — Offer Integration
> "Shall I add an `## Adversarial Review` section to the document with these findings?"

---

## In-Flight Doubt (code and architecture decisions)

Use when a **non-trivial** decision is about to stand (branching logic, cross-module change, unverified invariant, irreversible deploy). Skip for formatting, obvious one-liners, or pure reads.

Copy the checklist from `references/adversarial-prompt.md` (full prompt library for code, plans, architecture):
1. **CLAIM** — decision + why it matters (2–3 lines)
2. **EXTRACT** — smallest artifact + contract only (no your reasoning)
3. **DOUBT** — fresh-context reviewer with adversarial prompt (never pass CLAIM)
4. **RECONCILE** — classify each finding (see prompt file)
5. **STOP** — trivial findings, 3 cycles, or user override

**TDD note:** a failing repro test from `test-driven-development` satisfies DOUBT for behavioral claims.

**Interactive sessions:** after single-model doubt, offer cross-model second opinion; announce skip in CI/non-interactive runs.

---

## Fresh-Context Adversarial Mode (documents / strategy)

For high-stakes **documents** (product-soul, PRD, design doc), run the three phases above, then escalate with `references/adversarial-prompt.md` (CLAIM list → EXTRACT evidence → DOUBT with fresh context → RECONCILE → STOP).

Escalate when: external commit imminent; 0–1 critical findings on first pass; reviewer agreed too fast. Optional cross-model DOUBT for highest stakes. **Doubt Theater:** 2+ cycles, zero actionable findings → stop and escalate (you are validating).

---

## Gotchas

- Generic critiques are useless. "Timeline is aggressive" is noise. "Timeline assumes third-party API integration takes 2 weeks — historically takes 6–8 weeks" is adversarial hat.
- Phase order matters. Running Phase 3 before Phase 1 critiques solutions built on wrong foundations.
- The strongest adversarial critique is often the simplest: "Does this solve the problem users actually have?"
- Complementary to `inversion`: inversion asks "what is the opposite?" — adversarial hat asks "what is wrong with what we have?"

---

## Example

<examples>
  <example>
    <input>Adversarial hat on our product-soul — community feature to drive retention</input>
    <output>
CRITICAL FINDINGS
1. "Community drives retention" is stated as strategic premise but has no cited evidence for this segment. Research (Lenny Rachitsky 2023) shows community works for daily-use products. This product's usage is monthly invoicing — a different pattern.
   Resolution: Find 3 comparable monthly-use B2B SaaS products where community measurably improved retention. If not found, the premise needs revision.

2. PMF section states "12 active" without separating community-driven from product-driven activation. If those 12 were active before community existed, community's contribution is zero.
   Resolution: Separate activation cohorts — community access vs. no access.

SIGNIFICANT FINDINGS
1. No mechanism described for when founding members go quiet — which they will.
   Resolution: Define moderation and re-engagement playbook before launch.

WHAT WOULD NEED TO BE TRUE
1. Monthly-use B2B SaaS has documented cases of community improving retention >10%.
2. At least 5 of 12 active users want to connect with each other, not just the product team.

STRONGEST ELEMENTS
The PMF falsification condition ("if users complete integration once and never return, we are a tutorial") is excellent — apply the same rigour to the community hypothesis.
    </output>
  </example>
</examples>

---


---

## Common Rationalizations

| Excuse | Reality |
|--------|---------|
| "We're aligned already" | Alignment theater hides unstated objections until launch. |
| "Devil's advocate is negative" | Stress-testing now prevents expensive surprises later. |
| "We don't have time to argue" | One structured challenge pass is cheaper than a rework cycle. |

## Verification

- [ ] Strongest counter-argument stated in good faith (not a strawman)
- [ ] At least one plan change or explicit accept-risk decision recorded
- [ ] Assumptions challenged map to testable follow-ups
- [ ] Session ends with forward actions, not endless debate

## Red Flags

- Generic critique without named failure mode or evidence
- Phase 3 run before Phase 1 foundations are challenged
- Solutions critiqued without testing problem-solution fit
- Critique stops at timeline noise instead of core assumptions

## Prune Log
Last pruned: 2026-07-04
- No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)


## Impact Report

`Adversarial review: [document] Phases run: [D / C / Ch — all or subset] Critical: N | Significant: N | Minor: N Integrated into document: [yes / no]`