# Pre Mortem > Runs a focused pre-mortem only — prospective-hindsight failure analysis. Invoke via /pre-mortem only. - Skill: `chrisdavidson/pre-mortem-2` (Agent Skill) - Install (CLI): `npx skillmds@latest add chrisdavidson/pre-mortem-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/chrisdavidson/pre-mortem-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: chrisdavidson (https://skillmd.com/u/chrisdavidson) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/chrisdavidson/pre-mortem-2 --- # Focused Pre-Mortem Mode You are running in focused-pre-mortem mode. Execute the procedure below, produce its canonical output sections, then run the focused-mode validation step below — do not run the full 5-phase first-principles analysis. Skip Step 0 technique selection; the user has already chosen this technique by invoking the slash command directly. ## When to reach for this Use a pre-mortem once a plan has enough specificity to reason about particular failure modes, but before it is finalised and carries organizational momentum. Not the right tool for evaluating options (use trade-off analysis) or for tracing something that already went wrong (use 5-Whys). --- ## Framing Before any other step, adopt this premise explicitly: > It is approximately six months from now. This plan has failed — not merely > underperformed, but failed badly. That outcome is a fact. > Working backward: what caused it? This past-tense framing is not rhetorical. It bypasses the optimism bias that makes forward-looking risk lists generic. Do not skip it or soften it to "might fail" — the grammatical shift from possibility to accomplished fact is the mechanism. --- ## Procedure 1. **Restate the premise.** Before writing anything, say or write: "The plan has already failed. What caused it?" This re-anchors the prospective-hindsight frame before analysis begins. 2. **Write independently.** List every cause of the failure without filtering — write the full list before reviewing it. Do not discard causes that seem unlikely; the list is raw material, not a verdict. 3. **Interrogate the list adversarially.** Re-read each item and ask: "Would I have suppressed this in a group?" Items flagged by that question are often the highest-signal findings. 4. **Identify recurring patterns.** Look for failure causes that cluster — the same root (over-optimistic timeline, single point of dependency, assumption never validated). A cluster is a structural weakness in the plan, not an isolated risk. 5. **Act on findings.** Modify the plan to address the structural weaknesses, or explicitly accept the risk with a named mitigation. A pre-mortem with no downstream plan change was box-ticking. **Exit criterion:** The failure has been stated as having already happened, causes are written from that stance, causes are clustered into structural weaknesses, and every cluster has either a named plan change or an explicitly accepted risk with a named mitigation. A pre-mortem that ends without one of those two outcomes per cluster is box-ticking, not a finding. --- ## Example **Plan:** Host a dinner party for twelve people in two weeks, cooking a full three-course meal from scratch for the first time at this scale. **Framing applied:** It is two weeks from now. The dinner party has failed badly. What caused it? **Backward-derived failure causes:** - Underestimated preparation time; last two courses were served an hour late - A key ingredient unavailable the day before; no substitution plan - One course required equipment not owned and not sourced in advance - Two guests had dietary restrictions not asked about until the day of - Energy depleted by the time guests arrived; host unable to enjoy the evening **Pattern identified:** Every cause traces back to a single structural weakness — no dry run at smaller scale and no contingency check before commitment. The plan assumed novelty would resolve itself on the day. --- ## Failure modes **Forward-looking framing.** "What could go wrong?" produces a generic risk list. If causes feel speculative and mild, the past-tense premise was not adopted. **Running it too early.** A pre-mortem on a plan with insufficient specificity yields generic concerns. The plan must have enough detail to reason about particular failure modes — vague plans produce vague analyses. **Anchoring (in group settings).** When facilitated, the most senior voice in the room shapes the list. Run independent writing before any sharing — each participant writes silently before the group compares lists. **First-speaker anchoring.** The first cause named draws subsequent thinking toward it. Write exhaustively before ranking or grouping. **No follow-through.** A pre-mortem with no downstream plan change was box-ticking. Findings must modify the plan or be explicitly accepted with named mitigations. --- ## Handoff The probable failure causes identified here feed Phase 5 (Validate). Add the highest-signal structural weaknesses to the adversarial validation pass — each one is a weak-link candidate for the signed-off analysis to address or explicitly accept. ## Focused-mode validation **Check the output against its own completion condition before presenting it.** The procedure above states one, in whichever form this technique uses — an exit criterion, a stop test, or an output contract. Read that condition again and confirm the output actually produced meets every requirement it names, not just the ones that were easiest to satisfy. **This is a scope-proportionate check, not the six-criterion Self-Audit Gate.** That gate scores a six-section analysis document; this run produced one technique's output sections, not six, so walking all six criteria against it would score structure that was never produced. The larger of the two components: a focused run does not acquire evidence — it opens no cited source — so a claim resting on a source this run did not open stays marked rather than being resolved as confirmed. **Carry the mark forward.** Anything this run could not verify is carried into the output marked with a `?` rather than dropped or silently asserted as fact. **Revise once, then stop.** If the check fails, revise the output and check it again. Revise at most one time. If it still fails after that pass, present the output with the gap named rather than revising again. **End every run with a validation line, without exception.** State exactly one of the following, verbatim, never silently: - `Focused-mode validation: satisfied` - `Focused-mode validation: revised once, now satisfied` - `Focused-mode validation: not satisfied - ` Close with the reason this line is unconditional: a silent run is indistinguishable from a run that skipped the check. --- If a fuller analysis is needed afterward, invoke the main `first-principles` agent with this output as Known ground truths.