| name | prd-devils-advocate |
| description | Use when attacking a PRD's soundness before implementation — surfacing unstated assumptions, running a pre-mortem on how the feature fails in production, and auditing whether the research actually supports the chosen approach. Invoked by prd-review's adversarial phase, or directly via "devil's advocate this PRD", "PRD'yi çürüt", "what could go wrong with this spec", "pre-mortem this feature", "challenge this PRD's assumptions". PRD-scoped — maps every counter-argument to a PRD section. |
| license | MIT |
| metadata | {"author":"murat-aydogan","version":"1.0"} |
prd-devils-advocate
The adversarial half of PRD review. prd-review checks whether a spec is
complete and disciplined; this skill checks whether it is sound — whether
the idea survives contact with a hostile reader before it survives contact with
production. It is the Critic to the spec's Builder: the cheapest place to break
a plan is on paper.
Unlike the general the-fool skill, this one is locked to PRDs: it runs
its frameworks automatically (no interactive mode menu), it knows the PRD
section structure, and every counter-argument it produces is mapped to the
section that should answer it (§12 risk register, §12.5 failure modes, §17 open
questions, §9 security). It borrows the-fool's reasoning frameworks but
applies them to one object: the spec in front of it.
When to use
prd-review Phase 4 invokes it on the PRD under review (primary path).- The user directly asks to challenge / pre-mortem / stress-test a PRD.
When NOT to use: challenging a general idea, business decision, or
architecture with no PRD → use the-fool. Reviewing written code → use
review-project.
How it runs
Run all three frameworks against the PRD, in order. Each produces 2–4
counter-arguments. Do not ask the user to pick a mode — that is the-fool's
interactive behaviour; here the pass is automatic so it can be called
non-interactively by prd-review.
1. Pre-mortem — references/pre-mortem.md
"It is six months from now and this feature failed in production. What
happened?" Reason backward from concrete failure scenarios (load spikes,
throttling, partial failures, data corruption, cost blowups) to the gap in the
PRD that allowed it. Map each to §12 risk register / §12.5 failure
modes.
2. Assumption-attack — references/assumption-attack.md
List what the PRD takes for granted without stating: that a capability already
exists, that inputs are always valid, that the user is always authed, that an
external API behaves as imagined. Each silent assumption that, if false, breaks
the plan → map to §17 open questions (or §9 if security-relevant).
3. Evidence-audit — references/evidence-audit.md
Check §3.5 and any "best practice" / benchmark claim. Does the cited evidence
actually support the chosen approach, or is it hand-wave ("en iyi pratiktir")
or cherry-picked? Grade each claim: supported / overstated / unsupported.
Output
A compact block (folded into prd-review's report, or standalone):
Devil's Advocate — <path>
⚔ Pre-mortem: <failure scenario> → <PRD gap> → add to §12 / §12.5
⚔ Assumption: <silent assumption> — if false, <consequence> → §17
⚔ Evidence: <claim> is <overstated|unsupported> → cite or soften
Each line names the framework, the finding, and the PRD section that should
absorb it. 6–10 lines total for a typical PRD.
Bounded adversarial pressure
Attack until the criticism stops finding new gaps, then stop. The goal is to
surface the spec's real weaknesses, not to manufacture objections to a sound
plan. If a section already answers a challenge, say so and move on — do not
invent a problem to hit a quota. A PRD that survives all three frameworks
cleanly is a strong signal, and saying that plainly is part of the job.
Common mistakes
- Producing generic objections ("might not scale") instead of PRD-specific
ones tied to this feature's mechanics.
- Skipping the evidence-audit because §3.5 "looks researched" — that is exactly
where cherry-picking hides.
- Manufacturing objections to a sound spec to seem thorough. Bounded pressure:
stop when the gaps stop.
- Forgetting to map each finding to a section — an unmapped counter-argument
cannot be acted on.
