agentleFS
MbappeWUMbappeWU/murder-board/skills/pre-mortem/SKILL.md

pre-mortem

Skill15 starsChanged 49 days agoMITView on GitHub

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, 事前验尸, 风险评估, 复盘前置, 这个计划有什么坑.

30 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use brainstorm-experiments-existing, prioritize-assumptions and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • skytiger6724Skill

    brainstorm-experiments-existing

    Design experiments to test assumptions for an existing product — prototypes, A/B tests, spikes, and other low-effort validation methods. Use when validating assumptions, testing feature ideas cheaply, or planning product experiments.

    Also in 7 projects that use this

  • skytiger6724Skill

    prioritize-assumptions

    Prioritize assumptions using an Impact × Risk matrix and suggest experiments for each. Use when triaging a list of assumptions, deciding what to test first, or applying the assumption prioritization canvas.

    Also in 7 projects that use this

  • 45ckSkill

    pestle-analysis

    Also in 7 projects that use this

  • About-IntelligenceSkill

    positioning-ideas

    Brainstorm product positioning ideas differentiated from competitors.

    Also in 7 projects that use this

  • About-IntelligenceSkill

    product-name

    Brainstorm 5 unique, memorable product names with rationale aligned to brand values and target audience.

    Also in 6 projects that use this

  • nandanosqlSkill

    swot-analysis

    Conduct a structured SWOT analysis — Strengths, Weaknesses, Opportunities, Threats — that connects internal capabilities to external forces for strategic decision-making.

    Also in 9 projects that use this

  • +5 more from skytiger6724
  • +1 more from About-Intelligence

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 23 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Assume failure is certain: Never debate *whether* it fails.

    line 18
  2. Distinctive:

    Horizon: when would we know it failed?

    line 31
  3. Distinctive:

    Write 6–10 failure stories, each from a different angle.

    line 40
  4. Distinctive:

    Write 2–4 pre-committed decision rules, set now while heads are cool:

    line 68
  5. Very specific:

    If you can write files, save the result as pre-mortem-<topic>-<YYYY-MM-DD>.md.

    line 79
  6. Distinctive:

    If the user wants to run a pre-mortem *with their team*, produce a facilitation kit instead of (or in addition to) the analysis:

    line 83

“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Assume failure is certain. Never debate whether it fails. It has failed. The only question is why.
  2. 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.
  3. Specific to this plan. Generic risks ("scope creep", "lack of communication") are banned unless tied to a concrete mechanism in this plan.
  4. 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.
  5. Every top risk ends in an action with an owner and a date, or it's just worry.
  6. Mirror the user's language. 用户用中文,就全程中文。
  7. 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:

  1. Invite text (2–3 sentences): purpose, 45 minutes, psychological-safety framing ("we're not criticizing the plan; we're protecting it").
  2. 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).
  3. 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?").
  4. 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.