Pre Mortem

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

1. Fix the plan and a horizon. What's being attempted, and by when do we judge it?
2. Declare failure. Vividly: "It's [horizon]. The plan failed. It was a disaster." Sit in that world.
3. 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").
4. Rank by likelihood × impact. Score each cause on both; sort. The top of that list is where attention belongs.
5. 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

1. The failure scenario — 2–3 vivid sentences, past tense.
2. Ranked failure causes — a table or list: cause · likelihood (H/M/L) · impact (H/M/L). Lead with high×high.
3. The one fix — the single most leverage-rich mitigation. If you do nothing else, do this.
4. Early-warning signals — the cheap canaries that tell you a top risk is happening while there's still time.
5. (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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: 3243dwon
• Source: 3243dwon/clear-eye
• License: MIT

Install and usage instructions live in the source repository linked above.