Premortem
Imagine the plan already failed, then explain why. This "prospective hindsight" tense-shift
(Klein, HBR 2007) generates ~30% more failure causes than asking "what could go wrong?" — and
the causes are more specific. The skill turns that mechanism into a repeatable run that ends in
a revised plan, not just a list of worries.
Workflow Routing
| Trigger |
Workflow |
| "premortem this", "run a premortem", "what could kill this", high-stakes plan |
Workflows/RunPremortem.md (full: parallel deep-dive agents) |
| "quick premortem", small/personal decision, fast gut-check, thin context |
Workflows/QuickPremortem.md (solo single-pass, no fan-out) |
| "update the premortem skill", add/fix a workflow |
Workflows/Update.md |
Default to RunPremortem for anything with real stakes. Drop to QuickPremortem only when
the decision is small or the user explicitly wants speed.
The Mechanism (don't skip the framing)
The entire technique is one move: state that failure has already happened, with certainty, and
ask what caused it. Everything else is delivery. If a step doesn't help the user inhabit
"it already failed," cut it. Full evidence and citations: References/Methodology.md.
Quick Reference
- Frame in past tense. "It's [horizon]. [The plan] has failed. Here's why." Not "could fail."
- Generate causes independently first. In
RunPremortem, parallel agents must NOT see each
other's output — this is the anti-anchoring safeguard, and it is load-bearing.
- Demand plan-specific causes. Reject generic risks ("timeline slips"). Ground every cause in
actual plan details.
- Always land on action. Each retained risk → a mitigation + an early-warning signal. End with
a revised plan and a pre-launch checklist. A premortem with no follow-through is theater.
- Markdown is canonical. The transcript (
.md) is the record. HTML is an optional visual
artifact via Tools/GenerateReport.ts --html, never the primary output.
When NOT to run a premortem
- Vague concepts with no concrete plan — gather the plan first, or you'll generate generic risk.
- Decisions already irreversibly made — nothing to revise; value is low.
- Factual questions or creative feedback — wrong tool.
- Attacking an idea/argument in the abstract →
RedTeam. Current multi-view debate → Council.
Tools
Tools/GenerateReport.ts — turns a findings JSON (schema in References/Templates.md) into a
markdown report (default) or a self-contained HTML report (--html). Run with bun. See
Tools/GenerateReport.help.md.
Gotchas
The highest-density part of this skill. Add to it after every run that surprises you.
- The "30%" stat is about quantity, not correctness. The 1989 Mitchell/Russo/Pennington study
found prospective hindsight produces ~30% more reasons generated — NOT 30% better at
identifying the correct reasons. Klein's HBR paraphrase ("correctly identify") overstates it.
Never tell a user the premortem makes them "30% more accurate." It makes them more prolific and
specific. Citing it wrong makes the whole analysis look sloppy.
- Anchoring kills the run. If you generate causes sequentially (or let one agent see another's
output), the first failure named frames everything after it. Generate independently, then merge.
This is why
RunPremortem fans out parallel agents and explicitly forbids cross-talk.
- Generic risks are the #1 quality failure. "Budget overruns," "team gets distracted,"
"market shifts" apply to every plan and help no one. If a cause would survive find-and-replace of
the subject, it's too generic — force it to cite a real plan detail.
- Run it BEFORE commitment. A premortem after the money is spent and the team is emotionally
bought in becomes a ritual. Its value is in changing the plan, so it needs a changeable plan.
- Don't confuse it with RedTeam or Council. Premortem = imagined future failure of a
concrete plan, ending in a revised plan. RedTeam = adversarial attack on an arbitrary idea.
Council = multiple current perspectives debating. Overlapping vocabulary, different mechanisms.
- Thin context → generic output. If you can't state (1) what's being premortemed in one
sentence, (2) who's affected, (3) what success means, STOP and ask one question at a time. Don't
generate failures from nothing — that produces exactly the generic risk this technique exists to
avoid.
- Failure ≠ pessimism. The output is specific causal stories with mitigations, not a doom mood.
If the run reads as "everything is risky," it failed.
- Likelihood and severity are different axes. The most likely failure and the most dangerous
failure are usually not the same one. Surface both — that distinction is often the insight.
Customization
Before executing, check for user customizations at
~/.claude/PAI/USER/SKILLCUSTOMIZATIONS/Premortem/. If PREFERENCES.md exists, load and apply it
(e.g. preferred default horizon, report theme, number of failure agents). These override defaults.
If the directory does not exist, proceed with skill defaults. Do not put private/identity content
in this skill body — it belongs in SKILLCUSTOMIZATIONS.
🚨 Voice Notification (run on invocation)
curl -s -X POST http://localhost:31337/notify \
-H "Content-Type: application/json" \
-d '{"message": "Running the WORKFLOWNAME workflow in the Premortem skill to ACTION"}' \
> /dev/null 2>&1 &
Then output: Running the **WorkflowName** workflow in the **Premortem** skill to ACTION...
Examples
Example 1: Full premortem on a launch
User: "Premortem our paid-newsletter launch next month"
→ RunPremortem: gather context (what/who/success) → frame "it's 6 months out, the launch failed"
→ generate plan-specific causes → fan out 1 agent per cause (independent) → synthesize
most-likely + most-dangerous + hidden assumption + revised plan + checklist
→ write transcript .md, optionally GenerateReport.ts --html → 3-sentence chat summary
Example 2: Quick solo gut-check
User: "quick premortem on accepting this contractor role"
→ QuickPremortem: single-pass, no agents → past-tense framing → 5-8 specific causes with
likelihood/severity, hidden assumption, top mitigations → short markdown, no HTML
Example 3: Disambiguation from RedTeam
User: "poke holes in my argument that we should go remote-first"
→ This is attacking an ARGUMENT, not a plan-with-stakes → suggest RedTeam instead, or
reframe: "if you want to premortem the remote-first *rollout plan*, I can do that."
Execution Log
After completing any workflow, append a single JSONL entry:
echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Premortem","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/PAI/MEMORY/SKILLS/execution.jsonl
1---2name: premortem3description: Run a premortem on any plan, launch, product, hire, pricing change, strategy, or high-stakes decision. Uses Gary Klein's prospective-hindsight method — assume it already failed at a future date and work backward to surface every plan-specific cause, then produce a revised plan, mitigations, early-warning signals, and a pre-launch checklist. USE WHEN premortem this, run a premortem, what could kill this, future-proof this, stress test this plan, what am I missing here, find the blind spots, what could go wrong, am I missing anything, poke holes in this, where will this break, before I commit to this. NOT FOR adversarial attack on an arbitrary idea or argument (use RedTeam), current-state multi-perspective debate (use Council), network/system vulnerability testing (use Security), or simple feedback/factual questions. DO trigger when someone has a concrete plan or commitment where the cost of being wrong is high and the decision is still changeable.4---5
6# Premortem
7
8Imagine the plan **already failed**, then explain why. This "prospective hindsight" tense-shift
9(Klein, HBR 2007) generates ~30% more failure causes than asking "what could go wrong?" — and
10the causes are more specific. The skill turns that mechanism into a repeatable run that ends in
11a revised plan, not just a list of worries.
12
13## Workflow Routing
14
15| Trigger | Workflow |
16| ----------------------------------------------------------------------------- | ------------------------------------------------------------- |
17| "premortem this", "run a premortem", "what could kill this", high-stakes plan | `Workflows/RunPremortem.md` (full: parallel deep-dive agents) |
18| "quick premortem", small/personal decision, fast gut-check, thin context | `Workflows/QuickPremortem.md` (solo single-pass, no fan-out) |
19| "update the premortem skill", add/fix a workflow | `Workflows/Update.md` |
20
21**Default to `RunPremortem`** for anything with real stakes. Drop to `QuickPremortem` only when
22the decision is small or the user explicitly wants speed.
23
24## The Mechanism (don't skip the framing)
25
26The entire technique is one move: **state that failure has already happened, with certainty, and
27ask what caused it.** Everything else is delivery. If a step doesn't help the user inhabit
28"it already failed," cut it. Full evidence and citations: `References/Methodology.md`.
29
30## Quick Reference
31
32- **Frame in past tense.** "It's [horizon]. [The plan] has failed. Here's why." Not "could fail."
33- **Generate causes independently first.** In `RunPremortem`, parallel agents must NOT see each
34 other's output — this is the anti-anchoring safeguard, and it is load-bearing.
35- **Demand plan-specific causes.** Reject generic risks ("timeline slips"). Ground every cause in
36 actual plan details.
37- **Always land on action.** Each retained risk → a mitigation + an early-warning signal. End with
38 a revised plan and a pre-launch checklist. A premortem with no follow-through is theater.
39- **Markdown is canonical.** The transcript (`.md`) is the record. HTML is an optional visual
40 artifact via `Tools/GenerateReport.ts --html`, never the primary output.
41
42## When NOT to run a premortem
43
44- **Vague concepts with no concrete plan** — gather the plan first, or you'll generate generic risk.
45- **Decisions already irreversibly made** — nothing to revise; value is low.
46- **Factual questions or creative feedback** — wrong tool.
47- **Attacking an idea/argument in the abstract** → `RedTeam`. **Current multi-view debate** → `Council`.
48
49## Tools
50
51- `Tools/GenerateReport.ts` — turns a findings JSON (schema in `References/Templates.md`) into a
52 markdown report (default) or a self-contained HTML report (`--html`). Run with `bun`. See
53 `Tools/GenerateReport.help.md`.
54
55## Gotchas
56
57> The highest-density part of this skill. Add to it after every run that surprises you.
58
59- **The "30%" stat is about quantity, not correctness.** The 1989 Mitchell/Russo/Pennington study
60 found prospective hindsight produces ~30% **more reasons generated** — NOT 30% better at
61 identifying the _correct_ reasons. Klein's HBR paraphrase ("correctly identify") overstates it.
62 Never tell a user the premortem makes them "30% more accurate." It makes them more _prolific_ and
63 _specific_. Citing it wrong makes the whole analysis look sloppy.
64- **Anchoring kills the run.** If you generate causes sequentially (or let one agent see another's
65 output), the first failure named frames everything after it. Generate independently, then merge.
66 This is why `RunPremortem` fans out parallel agents and explicitly forbids cross-talk.
67- **Generic risks are the #1 quality failure.** "Budget overruns," "team gets distracted,"
68 "market shifts" apply to every plan and help no one. If a cause would survive find-and-replace of
69 the subject, it's too generic — force it to cite a real plan detail.
70- **Run it BEFORE commitment.** A premortem after the money is spent and the team is emotionally
71 bought in becomes a ritual. Its value is in _changing_ the plan, so it needs a changeable plan.
72- **Don't confuse it with RedTeam or Council.** Premortem = imagined _future failure_ of a
73 _concrete plan_, ending in a revised plan. RedTeam = adversarial attack on an arbitrary idea.
74 Council = multiple _current_ perspectives debating. Overlapping vocabulary, different mechanisms.
75- **Thin context → generic output.** If you can't state (1) what's being premortemed in one
76 sentence, (2) who's affected, (3) what success means, STOP and ask one question at a time. Don't
77 generate failures from nothing — that produces exactly the generic risk this technique exists to
78 avoid.
79- **Failure ≠ pessimism.** The output is specific causal stories with mitigations, not a doom mood.
80 If the run reads as "everything is risky," it failed.
81- **Likelihood and severity are different axes.** The _most likely_ failure and the _most dangerous_
82 failure are usually not the same one. Surface both — that distinction is often the insight.
83
84## Customization
85
86Before executing, check for user customizations at
87`~/.claude/PAI/USER/SKILLCUSTOMIZATIONS/Premortem/`. If `PREFERENCES.md` exists, load and apply it
88(e.g. preferred default horizon, report theme, number of failure agents). These override defaults.
89If the directory does not exist, proceed with skill defaults. Do not put private/identity content
90in this skill body — it belongs in SKILLCUSTOMIZATIONS.
91
92## 🚨 Voice Notification (run on invocation)
93
94```bash
95curl -s -X POST http://localhost:31337/notify \
96 -H "Content-Type: application/json" \
97 -d '{"message": "Running the WORKFLOWNAME workflow in the Premortem skill to ACTION"}' \
98 > /dev/null 2>&1 &
99```
100
101Then output: `Running the **WorkflowName** workflow in the **Premortem** skill to ACTION...`
102
103## Examples
104
105**Example 1: Full premortem on a launch**
106
107```
108User: "Premortem our paid-newsletter launch next month"
109→ RunPremortem: gather context (what/who/success) → frame "it's 6 months out, the launch failed"
110→ generate plan-specific causes → fan out 1 agent per cause (independent) → synthesize
111 most-likely + most-dangerous + hidden assumption + revised plan + checklist
112→ write transcript .md, optionally GenerateReport.ts --html → 3-sentence chat summary
113```
114
115**Example 2: Quick solo gut-check**
116
117```
118User: "quick premortem on accepting this contractor role"
119→ QuickPremortem: single-pass, no agents → past-tense framing → 5-8 specific causes with
120 likelihood/severity, hidden assumption, top mitigations → short markdown, no HTML
121```
122
123**Example 3: Disambiguation from RedTeam**
124
125```
126User: "poke holes in my argument that we should go remote-first"
127→ This is attacking an ARGUMENT, not a plan-with-stakes → suggest RedTeam instead, or
128 reframe: "if you want to premortem the remote-first *rollout plan*, I can do that."
129```
130
131## Execution Log
132
133After completing any workflow, append a single JSONL entry:
134
135```bash
136echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Premortem","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/PAI/MEMORY/SKILLS/execution.jsonl
137```
julianobarbosa