thinking-pre-mortem

Generates past-tense failure scenarios and converts them into plan gates and mitigations.

Updated May 24, 2026
One-click install
npx skills add https://github.com/MWest2020/skill-forge --skill thinking-pre-mortem-mwest2020
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: thinking-pre-mortem
Source: https://github.com/MWest2020/skill-forge/tree/main/skills/thinking-pre-mortem
Command: npx skills add https://github.com/MWest2020/skill-forge --skill thinking-pre-mortem-mwest2020

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Plans often fail from risks nobody articulated before execution. This Skill forces prospective hindsight: assume the plan already failed, enumerate concrete failure paths, and reverse each one into verifiable prevention requirements bound to owners, checkpoints, and ship gates. ## Core Features & Use Cases - Past-Tense Failure Framing: Sets a concrete post-deadline failure scenario so the team explains a happened failure rather than vaguely predicting one. - Reverse Path Analysis: For each top risk, derives necessary conditions, inverts them into prevention requirements, and binds owner, verification checkpoint, and ship/stage gate. - Over-Application Guards: Explicit stop rules prevent theater — skip reversible chores, mid-incident firefighting, and risks already enforced by live gates like CI or canaries. - Use Case: Before a major launch, run a pre-mortem to surface the top 3-5 failure paths (e.g., data loss, no adoption, SLA breach) and convert each into gated plan changes before kickoff. ## Quick Start Run a pre-mortem on my launch plan: assume it failed by the deadline, list the top failure reasons, and turn each into a mitigation with an owner and a ship gate.

Frequently Asked Questions about thinking-pre-mortem

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a pre-mortem analysis on a project plan?

Set a past-tense failure frame with a date and outcome, brainstorm failure reasons across technical, process, and people categories, then prioritize the top 3-5 by likelihood times impact. Invert each risk's necessary conditions into prevention requirements with owners and gates.

What is the difference between a pre-mortem and a risk brainstorm?

A pre-mortem assumes the failure already happened in past tense, which produces more concrete causes than asking what could go wrong. It also requires each top risk to bind to a verifiable plan change, not just a list of concerns.

When should I not use a pre-mortem?

Skip it for small, cheaply reversible work, mid-incident firefighting, and risks already enforced by live gates like CI, canaries, or rollback. Also skip it if a mature risk register already covers the same failure paths with owners and checks.

Why does a pre-mortem produce generic risks like scope creep?

Generic risks appear when failure reasons are not tied to the specific plan. Force a second pass asking what the plan most needed to be true that was not, and drop any risk that cannot bind to a concrete plan gate.

How do I know when a pre-mortem is complete?

It is complete when each top risk has a bound mitigation or prevention gate with an owner and verification checkpoint. A pre-mortem that produces no plan changes is incomplete, and further generic restatements signal it is time to stop.