premortem

Name: premortem
Author: PabloNAX

30stars0forks

How to install premortem?

pablonax/premortem-skill/premortem

$npx -y skills add PabloNAX/premortem-skill --skill premortem

Installs into the current project.

Summary

Run a premortem on any plan, launch, product, hire, strategy, or decision. Assumes it already failed 6 months from now and works backward to find every reason why. Produces a revised plan with blind spots exposed. MANDATORY TRIGGERS: 'premortem this', 'premortem my', 'run a premo

Files · 1

View on GitHub

SKILL.md

1	# Premortem
2
3	A premortem is the opposite of a postmortem. Instead of figuring out what went wrong after something fails, you imagine it already failed and figure out why before you start.
4
5	The method comes from psychologist Gary Klein. He published it in Harvard Business Review. Daniel Kahneman (the Nobel Prize-winning psychologist behind "Thinking, Fast and Slow") called it his single most valuable decision-making technique. Google, Goldman Sachs, and Procter & Gamble all use it before major decisions.
6
7	The core insight: when you ask people "what could go wrong?" they give you cautious, hedged answers. When you say "this already failed, tell me why," their brains switch into narrative mode and generate way more specific, creative, honest reasons. Researchers at Wharton and Cornell called this "prospective hindsight" and found it significantly increases the ability to identify causes of future outcomes.
8
9	The reason this matters for AI-assisted decisions: Claude defaults to agreeable, optimistic responses. If you ask "is this a good plan?" it will find reasons to say yes. The premortem breaks this pattern by forcing the frame into "this is dead, explain how it died." Claude stops looking for reasons your plan will work and starts explaining how it fell apart.
10
11	---
12
13	## when to run a premortem
14
15	Good premortem targets:
16	- A product or feature you're about to build
17	- A launch plan with money or reputation on the line
18	- A pricing change or business model shift
19	- A hire you're about to make
20	- A strategy or positioning pivot
21	- A partnership or deal you're evaluating
22	- Any commitment where the cost of being wrong is high
23
24	Bad premortem targets:
25	- Vague ideas with no concrete plan yet (help them plan first, then premortem)
26	- Questions with one right answer (just answer them)
27	- Requests for creative feedback on a draft (that's editing, not a premortem)
28	- Decisions that are already made and irreversible (a premortem is only useful when you can still change course)
29
30	---
31
32	## context gathering (the minimum bar)
33
34	A premortem is only as good as the context it runs on. Vague input produces vague failure scenarios that help nobody. Before running the premortem, you need to hit a minimum context threshold.
35
36	### step 1: scan for existing context
37
38	Before asking the user anything, look for context that's already available:
39
40	A. The current conversation. The user may have been discussing a plan, a launch, a product, or a decision earlier in this session. Read back through the conversation and extract whatever's relevant.
41
42	B. The workspace. Quickly scan for files that might contain relevant context:
43	- `CLAUDE.md` or `claude.md` (business context, preferences, constraints)
44	- Any `memory/` folder (audience profiles, business details, past decisions)
45	- Files the user explicitly referenced or attached
46	- Any project files, briefs, or plans that relate to the thing being premortemed
47
48	Use `Glob` and quick `Read` calls. Don't spend more than 30 seconds on this. You're looking for the key files that would ground the failure scenarios in reality.
49
50	### step 2: evaluate context sufficiency
51
52	After scanning, check whether you have enough to run a useful premortem. You need three things:
53
54	1. What is it? — A clear understanding of the thing being premortemed (a product, a launch, a hire, a pricing change, a strategy). You need to be able to describe it back to the user in one sentence.
55
56	2. Who is it for / who does it affect? — The audience, the customer, the team, the stakeholders. Failure scenarios depend heavily on who's involved.
57
58	3. What does success look like? — What outcome is the user hoping for? Failure is defined by inverting success. If you don't know what success means, you can't define what failure means.
59
60	### step 3: fill gaps conversationally
61
62	If you have all three, proceed immediately to the premortem. Don't ask unnecessary questions.
63
64	If you're missing one or more, ask for the most important missing piece first. One question at a time. Evaluate after each answer whether you now have enough. Keep asking until the threshold is met, but never ask more than you need.
65
66	Examples of focused context questions:
67	- "What specifically are you about to launch/build/decide?" (if you

People who liked this also viewed

6 picks

Type

premortem

30stars0forks

View on GitHub

How to install premortem?

pablonax/premortem-skill/premortem

$npx -y skills add PabloNAX/premortem-skill --skill premortem

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Premortem
2
3	A premortem is the opposite of a postmortem. Instead of figuring out what went wrong after something fails, you imagine it already failed and figure out why before you start.
4
5	The method comes from psychologist Gary Klein. He published it in Harvard Business Review. Daniel Kahneman (the Nobel Prize-winning psychologist behind "Thinking, Fast and Slow") called it his single most valuable decision-making technique. Google, Goldman Sachs, and Procter & Gamble all use it before major decisions.
6
7	The core insight: when you ask people "what could go wrong?" they give you cautious, hedged answers. When you say "this already failed, tell me why," their brains switch into narrative mode and generate way more specific, creative, honest reasons. Researchers at Wharton and Cornell called this "prospective hindsight" and found it significantly increases the ability to identify causes of future outcomes.
8
9	The reason this matters for AI-assisted decisions: Claude defaults to agreeable, optimistic responses. If you ask "is this a good plan?" it will find reasons to say yes. The premortem breaks this pattern by forcing the frame into "this is dead, explain how it died." Claude stops looking for reasons your plan will work and starts explaining how it fell apart.
10
11	---
12
13	## when to run a premortem
14
15	Good premortem targets:
16	- A product or feature you're about to build
17	- A launch plan with money or reputation on the line
18	- A pricing change or business model shift
19	- A hire you're about to make
20	- A strategy or positioning pivot
21	- A partnership or deal you're evaluating
22	- Any commitment where the cost of being wrong is high
23
24	Bad premortem targets:
25	- Vague ideas with no concrete plan yet (help them plan first, then premortem)
26	- Questions with one right answer (just answer them)
27	- Requests for creative feedback on a draft (that's editing, not a premortem)
28	- Decisions that are already made and irreversible (a premortem is only useful when you can still change course)
29
30	---
31
32	## context gathering (the minimum bar)
33
34	A premortem is only as good as the context it runs on. Vague input produces vague failure scenarios that help nobody. Before running the premortem, you need to hit a minimum context threshold.
35
36	### step 1: scan for existing context
37
38	Before asking the user anything, look for context that's already available:
39
40	A. The current conversation. The user may have been discussing a plan, a launch, a product, or a decision earlier in this session. Read back through the conversation and extract whatever's relevant.
41
42	B. The workspace. Quickly scan for files that might contain relevant context:
43	- `CLAUDE.md` or `claude.md` (business context, preferences, constraints)
44	- Any `memory/` folder (audience profiles, business details, past decisions)
45	- Files the user explicitly referenced or attached
46	- Any project files, briefs, or plans that relate to the thing being premortemed
47
48	Use `Glob` and quick `Read` calls. Don't spend more than 30 seconds on this. You're looking for the key files that would ground the failure scenarios in reality.
49
50	### step 2: evaluate context sufficiency
51
52	After scanning, check whether you have enough to run a useful premortem. You need three things:
53
54	1. What is it? — A clear understanding of the thing being premortemed (a product, a launch, a hire, a pricing change, a strategy). You need to be able to describe it back to the user in one sentence.
55
56	2. Who is it for / who does it affect? — The audience, the customer, the team, the stakeholders. Failure scenarios depend heavily on who's involved.
57
58	3. What does success look like? — What outcome is the user hoping for? Failure is defined by inverting success. If you don't know what success means, you can't define what failure means.
59
60	### step 3: fill gaps conversationally
61
62	If you have all three, proceed immediately to the premortem. Don't ask unnecessary questions.
63
64	If you're missing one or more, ask for the most important missing piece first. One question at a time. Evaluate after each answer whether you now have enough. Keep asking until the threshold is met, but never ask more than you need.
65
66	Examples of focused context questions:
67	- "What specifically are you about to launch/build/decide?" (if you

People who liked this also viewed

6 picks

Type