---
name: Pre-Mortem Analysis
slug: pre-mortem-analysis
category: AI Engineering
description: Pre-Mortem Analysis assumes a plan has already failed and works backward to identify concrete causes. Use it before kickoff, launch, or other high-risk commitments to turn risks into mitigations and verification gates.
github: "https://github.com/tjboudreaux/cc-thinking-skills/tree/main/skills/thinking-pre-mortem"
language: JavaScript
stars: 969
forks: 133
install: "npx degit https://github.com/tjboudreaux/cc-thinking-skills/tree/main/skills/thinking-pre-mortem ~/.claude/skills/thinking-pre-mortem"
installs_to: ~/.claude/skills/thinking-pre-mortem
source_path: skills/thinking-pre-mortem/SKILL.md
collection_size: 25
category_size: 2451
collection_url: "https://dirskills.com/collections/tjboudreaux/cc-thinking-skills"
added: 2026-08-21T05:15:04.900Z
last_synced: 2026-08-21T05:15:04.900Z
canonical_url: "https://dirskills.com/skills/pre-mortem-analysis"
---

# Pre-Mortem Analysis

Pre-Mortem Analysis assumes a plan has already failed and works backward to identify concrete causes. Use it before kickoff, launch, or other high-risk commitments to turn risks into mitigations and verification gates.

**Install:**

```bash
npx degit https://github.com/tjboudreaux/cc-thinking-skills/tree/main/skills/thinking-pre-mortem ~/.claude/skills/thinking-pre-mortem
```

## README

# Pre-Mortem Analysis

**Core rule:** Prospective hindsight beats "what could go wrong?" Assume the plan has already failed (past tense), generate concrete failure paths, reverse them into prevention requirements, and bind each top path to a verifiable plan change.

## When to Use

- Before kickoff, major technical commitment, high-risk sprint work, launch, or release.
- After a plan looks solid but before execution, especially when optimism or overconfidence is likely.
- When a decision is costly to reverse and risks are still implicit rather than enforced.

## When NOT to Use

- Work is small, local, and cheaply reversible — skip the ceremony.
- You are mid-incident under time pressure — act now (OODA / scientific method); pre-mortem is pre-execution.
- You would only emit generic risks ("scope creep", "requirements unclear") that do not bind to this plan.
- Risks are already enforced by live gates (CI, canary, rollback, alerts) with no residual unlisted path.
- A mature risk register already covers the same specific failure paths with owners and checks.

## Procedure

1. **Set the failure frame in past tense:** "It is [post-deadline date]. The plan failed: [rollback / data loss / no adoption / SLA breach]." Explaining a happened failure is required; predicting one is not enough.
2. **Generate failure reasons before filtering:** sweep technical, process, assumptions, dependencies/external, and people. Force a second pass: "What did the plan most need to be true that was not?" Collect breadth first (aim for many distinct reasons); do not rank mid-sweep.
3. **Prioritize:** group by theme; score likelihood × impact; keep the top 3–5 concrete risks (drop generics that do not bind).
4. **Failure-first reverse analysis (absorbed reverse path):** for each top risk, (a) restate the failed outcome in past tense, (b) list **necessary/enabling conditions** that had to be true for that failure, (c) **invert** each condition into a verifiable prevention requirement (avoid/require rule + check), (d) bind **owner, verification checkpoint, and ship/stage gate**.
5. **Mitigate and update the plan:** for each top risk, attach mitigation steps, spike/contingency if needed, and the reverse-analysis prevention requirements as explicit plan gates. A pre-mortem with no plan change is incomplete.
6. **Stop when** top risks each have a bound mitigation or prevention gate, or when further reasons are only generic restatements — then ship the updated plan, do not keep brainstorming.

## Output

1. **Failure scenario** — past-tense disaster frame with date and failed outcome.
2. **Failure reasons** — unfiltered list, then prioritized top 3–5 with likelihood × impact.
3. **Reverse paths** — for each top risk: necessary conditions → inverted prevention requirements.
4. **Mitigations** — owner, verification checkpoint, ship/stage gate per top risk.
5. **Plan deltas** — concrete tasks, spikes, contingencies, and gates added to the plan.

## Verification

- **Falsify/stop:** if no plan-specific failure path can be stated in past tense with necessary conditions, stop — you are generating theater, not risk. If a "mitigation" has no verification checkpoint, it is not done.
- **Over-application guard:** do not pre-mortem reversible chores, mid-incident firefighting, or systems that already enforce the same paths. Do not leave abstract risks as "mitigate later"; either invert them into gates or drop them as non-actionable.