| name | premortem |
| description | Run a premortem on a plan, launch, product, hire, strategy, or decision — assumes it failed 6 months from now and works backward to find every reason why, then produces a revised plan. Use when the user has a concrete plan or commitment with high cost-of-being-wrong and asks to "premortem", "stress test", "find blind spots", "poke holes", "what could kill this", or "what am I missing". Skip for vague ideas without a plan, simple feedback requests, factual questions, or already-irreversible decisions. |
| allowed-tools | Read, Glob, Grep, Write, Bash, Agent |
Premortem
Imagine the plan already failed. Work backward to find why. Based on Gary Klein's HBR method — the "this is dead, explain how it died" frame produces more specific, honest failure modes than "what could go wrong?".
This breaks Claude's default agreeableness: instead of looking for reasons the plan works, you're explaining how it fell apart.
When to run
Good targets: product/feature launches, pricing changes, hires, strategy pivots, partnerships, any commitment where being wrong is expensive.
Bad targets: vague ideas (help plan first), factual questions (just answer), draft feedback (that's editing), already-irreversible decisions.
If the user wants multiple perspectives on a current decision rather than failure analysis, suggest a different tool — premortems specifically simulate post-failure hindsight.
Step 1 — Gather minimum context
You need three things before running:
- What is it? — describable in one sentence
- Who is it for / who does it affect?
- What does success look like? — failure is success inverted
Scan first, ask second. Check the conversation, then run at most 2-3 Glob/Read calls for: CLAUDE.md, memory/ folders, files the user referenced, related project briefs.
If something's missing, ask one focused question at a time. Don't interrogate — infer when you can.
Step 2 — Set the frame explicitly
Once context is sufficient, say plainly:
"It's 6 months from now. [The plan] has failed. We're looking back to understand what went wrong."
This framing is the mechanism. Don't skip it.
Step 3 — Generate failure reasons
Produce a comprehensive list of genuine failure reasons. Each:
- Specific to this plan (not generic)
- Grounded in details the user provided
- A real threat (not a minor edge case)
State each in 1-2 sentences. The number is whatever's real — could be 3, could be 9. Don't pad. Don't truncate.
Step 4 — Deep-dive agents in parallel
Spawn one agent per failure reason in a single message with multiple Agent tool calls so they run concurrently. Each agent investigates one failure independently.
Agent prompt template (substitute the bracketed sections before sending):
You are an investigator in a premortem. You've been assigned one specific failure to analyze.
THE PLAN:
[what it is, who it's for, success criteria, relevant workspace context]
FRAME: It is 6 months from now. This plan has failed.
YOUR ASSIGNED FAILURE: [the specific failure reason from step 3]
Write the story of how this specific failure played out. Be concrete. Use details from the plan.
Output (under 300 words total):
1. THE FAILURE STORY — 2-3 paragraph narrative of how it played out, naming specific moments where things went wrong.
2. THE UNDERLYING ASSUMPTION — the one thing the user took for granted that made this failure possible. One sentence.
3. EARLY WARNING SIGNS — 1-2 concrete, observable signals the user could watch for. Things you can see or measure, not vague feelings.
Be direct. Don't hedge. Don't sugarcoat.
Step 5 — Synthesis
Read every deep-dive and produce:
- Most Likely Failure — most probable given what you know. Why.
- Most Dangerous Failure — worst damage if it happened, even if less likely.
- The Hidden Assumption — the single biggest thing the user is taking for granted. Often where the real value lives.
- The Revised Plan — concrete changes mapped to specific failure modes. Not "consider your pricing" — "test pricing at $X with 20 people before committing publicly."
- Pre-Launch Checklist — 3-5 things to verify, test, or put in place before executing. Each prevents or detects one failure mode.
Step 6 — Generate report
Save two files to the current working directory (confirm with the user if CWD looks wrong, e.g., a system path):
premortem-report-YYYYMMDD-HHMMSS.html — visual reportpremortem-transcript-YYYYMMDD-HHMMSS.md — full transcript (gathered context, raw failure list, all agent deep-dives, synthesis)
Use a real timestamp from date +%Y%m%d-%H%M%S.
HTML design:
- Single self-contained file with inline CSS
- Dark background (e.g.,
#0a0e1a), clean typography, scannable
- Synthesis section (most likely / most dangerous / hidden assumption / revised plan / checklist) at the top — most users read this first
- One card per failure reason below: header, failure story, underlying assumption, early warning signs. Distinct accent colors per card.
- Footer with timestamp and what was premortemed
After writing, open the HTML report:
open premortem-report-YYYYMMDD-HHMMSS.html
(macOS. On Linux, use xdg-open.)
Step 7 — Chat summary
In the chat, give a 3-sentence summary: most likely failure, hidden assumption, single most important plan revision. The HTML has the rest.
Step 8 — Offer to chain
After the summary, offer one line: "Want me to convene the LLM council on the revised plan to pressure-test whether the revisions are right?" Skip the offer if the revised plan is trivially small or the user signaled closure.
Principles
- Always parallel. All failure agents in one message. Sequential leaks earlier reasoning into later analysis.
- Always set the frame. "Already failed, explain why" is the psychological mechanism. Without it you get polite risk assessment.
- Comprehensive, not padded. Find every real failure. Don't stop at 3 if there are 7. Don't force 7 if there are 3.
- The synthesis is the product. Most users skim the cards and read the synthesis. Make it specific and actionable.
- Don't sugarcoat. Tell the user what they don't want to hear before reality does.
- Concrete revisions only. Every revised-plan item should be something the user can do this week.
- Respect the context threshold. One more question beats a generic premortem.
