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
- rahul-kulkarni105/skillstheir own version, first seen Nov 8, 2026
- cwhited26/pocket-agent-starter-skillstheir own version, first seen Nov 1, 2026
- yuusakuri/agent-skillstheir own version, first seen Nov 1, 2026
- Big-LAORE/Biblioth-que-de-skillstheir own version, first seen Nov 1, 2026
- daviszhen/agent-skillstheir own version, first seen Oct 25, 2026
- takayoshitoyoda05/claude-ml-templatetheir own version, first seen Oct 20, 2026
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.
skytiger6724Skillbrainstorm-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
skytiger6724Skillprioritize-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
45ckSkillpestle-analysis
Also in 7 projects that use this
About-IntelligenceSkillpositioning-ideas
Brainstorm product positioning ideas differentiated from competitors.
Also in 7 projects that use this
About-IntelligenceSkillproduct-name
Brainstorm 5 unique, memorable product names with rationale aligned to brand values and target audience.
Also in 6 projects that use this
nandanosqlSkillswot-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
Other versions30 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 30
- avelikiy/great_cto★ 112same name
- ysskrishna/ai-agent-skills★ 20same name
- jackjin1997/ClawForge★ 12same name
- sergeeey/Claude-cod-top-2026★ 9same name
- carlkibler/agent-skills★ 6same name
- fzfclee/consulting-skills★ 6same name
- broomva/skills★ 4same name
- Adhamxon/claude-code-skills★ 2same name
- skytiger6724/qwen-skills★ 2same name
- yuusakuri/agent-skills★ 2same name
20 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- boardroomSkill
- murder-boardSkill
- so-whatSkill
- sparringSkill
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
- Distinctive: line 18
Assume failure is certain: Never debate *whether* it fails.
- Distinctive: line 31
Horizon: when would we know it failed?
- Distinctive: line 40
Write 6–10 failure stories, each from a different angle.
- Distinctive: line 68
Write 2–4 pre-committed decision rules, set now while heads are cool:
- Very specific: line 79
If you can write files, save the result as pre-mortem-<topic>-<YYYY-MM-DD>.md.
- Distinctive: line 83
If the user wants to run a pre-mortem *with their team*, produce a facilitation kit instead of (or in addition to) the analysis:
“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.
Files
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.
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
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.

