pre-mortem
GitHub通过假设项目已失败并回溯原因,生成具体风险故事、预警信号及应对策略,用于在决策前识别潜在问题、降低风险。
Trigger Scenarios
Install
npx skills add MbappeWU/murder-board --skill pre-mortem -g -y
SKILL.md
Frontmatter
{
"name": "pre-mortem",
"license": "MIT",
"metadata": {
"author": "MbappeWU",
"version": "1.1.0"
},
"description": "Imagine the plan has already failed, then work backwards to why. Runs Gary Klein's pre-mortem on a project, launch, strategy, hire, investment or personal decision - vivid failure stories from several angles, ranked by likelihood and impact, early-warning signals, prevention, contingencies, tripwires (kill criteria) and the assumptions to test this week. Can also produce a facilitation script for running a pre-mortem with a team. Use when the user asks what could go wrong, wants to stress-test or de-risk a plan, is about to commit to something big, or says pre-mortem, risk review, 事前验尸, 风险评估, 复盘前置, 这个计划有什么坑."
}
Pre-mortem
A post-mortem explains why something died. A pre-mortem does it while there's still time to change the outcome. Research on "prospective hindsight" (Mitchell, Russo & Pennington, 1989) found that imagining an event has already happened raises the ability to identify reasons for it by about 30%. Gary Klein turned that into the pre-mortem.
Your job: make the failure feel real enough that the user can see it coming, then turn it into concrete defenses.
Rules
- Assume failure is certain. Never debate whether it fails. It has failed. The only question is why.
- Stories, not risk registers. Each failure is told as a short, specific story with a cause, a sequence and a moment when someone could have noticed.
- Specific to this plan. Generic risks ("scope creep", "lack of communication") are banned unless tied to a concrete mechanism in this plan.
- Find the silent killers. The deadliest failures are slow and invisible: morale drain, a key person quietly disengaging, a metric that looks fine while the real one decays.
- Every top risk ends in an action with an owner and a date, or it's just worry.
- Mirror the user's language. 用户用中文,就全程中文。
- Don't invent facts about their organization. Ask, or state the assumption explicitly.
Workflow
1. Frame (ask at most three questions, in one message)
- The plan: what exactly is being done (or read the doc/files if you can).
- Success: what does success look like, concretely, and by when?
- Horizon: when would we know it failed? (Default: the success date.)
Also useful if cheap to get: budget, team, key dependencies, what the user is most worried about.
2. Time-travel
Open with one line that sets the scene, dated at the horizon:
"It's [date]. [Plan] has failed, and not narrowly. Here is what happened."
3. Failure stories
Write 6–10 failure stories, each from a different angle. Pick the angles that fit:
- Execution: the plan was right but the doing broke (capacity, dependencies, sequencing).
- Customer / market: they didn't want it, didn't switch, or wanted something else.
- People & org: key person left, incentives misaligned, the team never bought in, a stakeholder quietly blocked it.
- Tech / operations: it didn't scale, broke in production, integration hell.
- Money: cost overrun, revenue later than planned, funding pulled.
- Competition & external: a competitor moved, regulation changed, the economy turned.
- Self-deception: the assumption everyone believed and nobody checked.
- Success disaster: it worked too well and something else broke.
Each story, in this shape:
📰 Headline: a short, newspaper-style headline of the failure What happened: 2–4 sentences with a concrete causal chain. First visible signal: the earliest moment someone could have noticed, and what they would have seen. Likelihood 1–5 · Impact 1–5
4. Rank and pick the top 3–5
Rank by Likelihood × Impact, and flag any silent killer (hard to see until too late) as top priority even if its score is lower.
5. Defenses for each top risk
- Prevent: what to change in the plan now to make this less likely.
- Detect: the leading indicator to watch, with a threshold ("weekly active pilots < 3 by week 4").
- Respond: the contingency if it happens anyway.
- Owner and date.
6. Tripwires (kill criteria)
Write 2–4 pre-committed decision rules, set now while heads are cool:
"If [measurable condition] by [date], we [stop / pivot / cut scope / escalate]."
These protect against the sunk-cost fallacy later.
7. Assumptions to test this week
List the 3–5 assumptions the plan depends on most, the cheapest test for each (a call, a prototype, a data pull), and what result would change the plan.
8. Verdict
End with one paragraph: is the plan Go, Go with changes (list them) or Rethink? Say which single change most improves its odds.
If you can write files, save the result as pre-mortem-<topic>-<YYYY-MM-DD>.md.
Team mode
If the user wants to run a pre-mortem with their team, produce a facilitation kit instead of (or in addition to) the analysis:
- Invite text (2–3 sentences): purpose, 45 minutes, psychological-safety framing ("we're not criticizing the plan; we're protecting it").
- Agenda (45 min): brief the plan (5) → "it failed; write why, alone, in silence" (8) → round-robin, one reason per person per round, no debate (15) → cluster and vote (7) → defenses for the top 3 (10).
- Facilitator lines for the tricky moments: the senior person going first (don't let them), people defending the plan ("park it, we're in failure-land"), vague reasons ("what exactly happened, and when?").
- Template for capturing the output (the table from steps 3–6).
Personal decisions
For personal plans (a career move, a big purchase, a move abroad), use the same method with personal angles: money, relationships, health and energy, identity ("I stopped enjoying it"), opportunity cost, and reversibility. Be direct but humane.
Version History
- c4469fe Current 2026-10-18 15:45


