| name | premortem |
| version | 1.0.0 |
| description | Stress-test a concrete plan, launch, hire, pricing change, strategy, or commitment by assuming it has already failed and reasoning backward. Use when the user has a real decision on the table and asks to 'premortem' it, 'stress-test' it, 'find blind spots', 'poke holes', or otherwise wants honest failure analysis instead of validation. Skip for vague ideas (help them plan first), questions with one right answer, or decisions that are already irreversible. |
Premortem
A premortem is the inverse of a postmortem: assume the plan has already failed, then reason backward to explain why. The method is Gary Klein's (HBR, 2007). Kahneman cited it as one of his most valuable decision tools. Wharton/Cornell research calls the underlying mechanism prospective hindsight — when people assume an outcome has occurred, they generate substantially more specific and honest causal explanations than when asked to forecast risks.
The reason it matters here: Claude defaults to validating plans. "Is this good?" gets agreement. "This already died — why?" forces the model into narrative explanation mode and produces specific, grounded failure stories instead of hedged risk-assessment language.
When NOT to run it
- Vague ideas with no concrete plan — help the user shape the plan first.
- Questions with a single correct answer — just answer them.
- Editing or feedback on a draft — that's editing, not a premortem.
- Decisions that can no longer change — there's nothing to act on.
Phase 1 — Context
Failure scenarios are only as good as the input. Before running, you need three things:
- What is it? A one-sentence description you can repeat back.
- Who does it affect? Audience, customer, team, stakeholders.
- What does success look like? Failure is the inversion of this.
First, scan what's already available — the current conversation, CLAUDE.md, any memory/ folder, files the user attached. Don't spend more than ~30 seconds. If you can infer an answer, don't ask.
Then ask only for what's missing, one question at a time. Stop asking the moment the threshold is met.
You also need a decision horizon — when would failure become evident? Pick the timeframe that fits the decision (a pricing change might fail in 4 weeks; a strategic pivot in 12–18 months). Default to asking the user; don't hardcode "6 months."
Phase 2 — Frame and generate
State the frame explicitly:
"It is [horizon] from now. [The plan] has failed. We're looking back to understand why."
Then generate every genuine failure reason. Be specific to this plan — not generic risk-management advice. Stop when you've exhausted real ones, not at a number. Some plans have 3 real failure modes; others have 9.
Each reason should be:
- Specific to the plan's actual details
- A genuine threat (not a minor inconvenience or extreme edge case)
- Stated in 1–2 sentences
Phase 3 — Depth (conditional)
For each failure mode, you can optionally go deeper: a short narrative of how it played out, the underlying assumption that made it possible, and 1–2 observable early-warning signs.
When to fan out to parallel sub-agents: high-stakes decision (significant money, reputation, or irreversibility), 5+ failure modes, user explicitly asks for depth. Each sub-agent takes one failure reason with the full plan context and produces failure story + assumption + warning signs.
When to stay inline: smaller decisions, fewer failure modes, time-sensitive sessions. Write the depth analysis directly. The synthesis is what matters — fan-out is a tool, not a default.
If you fan out, spawn all agents in a single message so they run in parallel.
Phase 4 — Synthesis (always)
This is the product. Produce:
- Most likely failure — which scenario is most probable, and why.
- Most dangerous failure — which would cause the most damage if it hit, even if less likely.
- The hidden assumption — the single biggest thing the user is taking for granted that they probably haven't questioned. This is usually where the real value lives.
- Revised plan — concrete changes, each mapped to a specific failure scenario. Not "consider your pricing" but "test pricing at $X with N people before committing publicly."
- Pre-launch checklist — 3–5 things to verify, test, or put in place before executing. Each one prevents or detects a specific failure mode.
Deliver the synthesis in chat. Keep it specific, direct, and free of hedging. Don't sugarcoat — the entire point is to surface what the user doesn't want to hear before reality does.
Phase 5 — Optional artifacts
By default, the synthesis lives in chat. Offer artifacts only when warranted:
- HTML report — only if the user wants something to share, revisit, or present. Ask first. Keep styling minimal unless they specify.
- Markdown transcript — only if the user asks to keep a record.
Don't write files by default. A premortem of a hire decision over coffee shouldn't drop two artifacts on the user.
Phase 6 — Memory
A premortem produces exactly the kind of insight worth keeping: a hidden assumption the user was making, or a validated decision-making pattern. At the end:
- If a
memory/ directory exists at ~/.claude/projects/<project-id>/memory/ (auto-memory) or in the project, offer to save the hidden assumption as a feedback or project memory — whichever fits.
- Don't save reflexively. Ask. The user knows whether the assumption generalizes beyond this one decision.
Operating notes
- Set the failure frame explicitly every time. "This already failed" is the load-bearing mechanism. Without it, the analysis collapses into polite risk assessment.
- Be honest, not exhaustive. Don't pad to hit a number. Don't truncate to be tidy.
- The revised plan must be actionable this week. If it's not, it's a wish.
- Ground every failure mode in actual plan details. If a failure reason would apply to any plan, it's not specific enough.
- Respect the context threshold. A premortem on insufficient context produces generic failures and wastes the user's time. Ask the missing question.
