Before committing to a plan or launch, assume it has already failed and reason backward through why — prospective hindsight surfaces risks that "what could go wrong?" misses.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/thinking-pre-mortem
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Before committing to a plan or launch, assume it has already failed and reason backward through why — prospective hindsight surfaces risks that "what could go wrong?" misses.
📊 Stats
Stars863
Forks126
LanguageJavaScript
LicenseMIT
📦 Ships with thinking-skills
</> SKILL.md
thinking-pre-mortem.SKILL.md
---name: thinking-pre-mortem
description: Before committing to a plan or launch, assume it has already failed and reason backward through why — prospective hindsight surfaces risks that "what could go wrong?" misses.
---# Pre-Mortem Analysis
## Overview
The pre-mortem, developed by psychologist Gary Klein, uses "prospective hindsight": instead of asking "What could go wrong?", assume the plan HAS failed and reason backward through why. Stating failure as already-happened surfaces concrete risks that forward-looking risk assessment glosses over.
**Core Principle:** It's easier to explain a failure that "already happened" than to predict one. Use that asymmetry productively in a single reasoning pass.
## When to Use
- Project kickoff (before work begins)
- Before committing to a major technical decision
- Sprint planning for high-risk work
- Before launch or major release
- When team seems overconfident
- After a plan is formed but before execution
Decision flow:
```
Starting significant work? → yes → Plan looks solid / on track? → yes → PRE-MORTEM ESSENTIAL
↘ no → Pre-mortem still valuable
↘ no → Standard risk assessment may suffice
```
## When NOT to Use
- The work is small, local, and reversible — failure is cheap to undo, so skip the ceremony.
- You're mid-incident under time pressure — act on the likely cause now (ooda/occams-razor); pre-mortem belongs *before* execution, not during firefighting.
- You'd only generate generic risks ("requirements unclear", "scope creep") that don't bind to this specific plan — stop if nothing concrete surfaces.
- The risks are already enforced by automated gates (CI, canary, rollback) — don't re-list what the system already catches.
## Trigger Card
Before committing to a plan or launch where optimism may be hiding risks:
1. **Assume it has already failed** — "It's six months later. The project was a disaster. What happened?"
2. **List concrete failure reasons** — specific to THIS plan, not generic. Why did it actually fail?
3. **Mitigate the top 3-5** — for each top failure reason, add a concrete safeguard or change the plan.
Skip if you'd only generate generic risks that don't bind to this specific plan. If risks are already enforced by automated gates (CI, canary, rollback), don't re-list what the system already catches. For a full launch risk review, run the full procedure.
## The Process
### Step 1: Set the Failure Frame
Adopt the stance that the plan has already failed, stated in past tense:
> "It is [future date, post-deadline]. This plan didn't just slip — it failed. The launch was rolled back / the migration corrupted data / adoption never happened."
Past tense is what makes this work: you are *explaining* a failure, not *predicting* one.
