| name | pre-mortem |
| description | Find what will kill a plan before it's committed to — by assuming it already failed and working backwards to the causes. Based on Gary Klein's pre-mortem technique. Unlike generic "what are the risks?" brainstorming, this skill imagines a specific, vivid failure six months out, reasons back to the most likely causes, ranks them by likelihood × impact, and prescribes the single highest-leverage fix. Use it on project plans, launches, strategies, architectures, migrations, investments, and big decisions. Trigger on phrases like "poke holes in this", "what could go wrong?", "stress-test my plan", "pre-mortem", "red-team this", "why might this fail?", or any request to surface the failure modes of a plan before acting on it. |
Pre-Mortem
A post-mortem asks why something died. A pre-mortem runs it before you commit: imagine the plan has already failed, then reason backward to why. Prospective hindsight makes people name risks they'd otherwise stay politely quiet about.
Core principle
Don't ask "what are the risks?" (vague, easy to wave away).
Say "It's six months later and this failed badly. What happened?" — then explain the failure as if it already occurred.
The process
- Fix the plan and a horizon. What's being attempted, and by when do we judge it?
- Declare failure. Vividly: "It's [horizon]. The plan failed. It was a disaster." Sit in that world.
- Generate causes. List the reasons it failed — concrete, specific, in past tense ("the migration corrupted prod data because the dry-run skipped foreign keys"), not abstractions ("poor execution").
- Rank by likelihood × impact. Score each cause on both; sort. The top of that list is where attention belongs.
- Prescribe the one fix that matters most. For the top risks, the single highest-leverage mitigation — and a cheap early-warning signal that tells you it's materializing.
Output format
- The failure scenario — 2–3 vivid sentences, past tense.
- Ranked failure causes — a table or list: cause · likelihood (H/M/L) · impact (H/M/L). Lead with high×high.
- The one fix — the single most leverage-rich mitigation. If you do nothing else, do this.
- Early-warning signals — the cheap canaries that tell you a top risk is happening while there's still time.
- (Optional) Kill criteria — the line that, if crossed, means stop.
Worked example
Plan: Ship a payments rewrite to all users in 6 weeks.
Failure scenario: It's week 7. The cutover dropped ~2% of transactions for three days before anyone noticed; finance can't reconcile, support is on fire, and we've rolled back to a codebase nobody remembers.
Ranked causes:
| Cause | Likelihood | Impact |
|---|
| No transaction-level reconciliation between old/new during rollout | High | High |
| Big-bang cutover instead of % rollout | High | High |
| Edge-case currencies untested (only USD in staging) | Med | High |
| On-call didn't know the new system | Med | Med |
The one fix: Don't big-bang it. Run new + old in shadow mode reconciling every transaction, then ramp 1% → 100%. This alone defuses the top two risks.
Early-warning signals: Any non-zero reconciliation mismatch in shadow mode; a rise in payment-retry rate; support tickets mentioning "charged twice".
Kill criteria: >0.1% unreconciled at any rollout step → halt and roll back the increment.
Anti-patterns to avoid
- Listing vague risks ("scope creep", "bad communication") instead of specific failure mechanisms
- Skipping the ranking — a flat list of 20 risks helps no one
- Naming risks but prescribing no concrete fix or signal
- Politeness: the technique only works if you let it actually fail in the story
Part of the clear-eye pack — Claude skills for seeing what others miss.
