/thinking-pre-mortem

name: thinking-pre-mortem
description: Before committing to a plan or launch, assume it already failed and reason backward through concrete causes — convert failure paths into mitigations, gates, and stop checks.
disable-model-invocation: true

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.