Skip to content
Back to skills

Pre Mortem

ASecurity

Prospective hindsight — imagine the project already failed, then diagnose why. Surfaces hidden risks before commitment.

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 3, 2026
ai-agentsgotesting

Security analysis

A100/100

Scanned September 3, 2026

npx -y skills add martineserios/thebrana --skill pre-mortem --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Pre Mortem?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Pre Mortem
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/martineserios-pre-mortem-thebrana/badge)](https://www.skillsdirectory.com/skills/martineserios-pre-mortem-thebrana)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: pre-mortem
description: "Prospective hindsight — imagine the project already failed, then diagnose why. Surfaces hidden risks before commitment."
group: thinking
keywords: [pre-mortem, risk, failure, retrospective, prospective, planning, stress-test]
task_strategies: [spike, investigation]
stream_affinity: [roadmap, research]
allowed-tools:
  - Read
  - Glob
  - Grep
  - AskUserQuestion
status: experimental
source: "Gary Klein — Sources of Power (1999); Klein et al. — Performing a Project Premortem (HBR 2007)"
acquired: "2026-06-15"
---
# Pre-Mortem

**Imagine the project already failed. Now find out why.**

Gary Klein's prospective hindsight technique — forces the brain into a different mode than optimistic planning. Retrospective analysis of a hypothetical failure produces 2× more failure causes than prospective analysis.

---

## When to use

- Before committing to a plan, architecture, or major decision
- When the team is too confident or too aligned (groupthink risk)
- Before a launch, migration, or irreversible change
- When someone asks "what could go wrong?"

---

## Step 1 — Set the scene

State the project, plan, or decision clearly. Then say:

> "It is [6 months / 1 year] from now. We went ahead with this plan. It failed completely. What happened?"

If the subject is unclear, ask:
```
AskUserQuestion: "What plan or decision are we stress-testing?"
```

---

## Step 2 — Generate failure causes

Spend 5–10 minutes generating every plausible failure cause without filtering. Use these lenses:

| Lens | Prompt |
|------|--------|
| **Technical** | What broke, crashed, couldn't scale, or had a hidden bug? |
| **Human/team** | Who burned out, left, got blocked, or misunderstood? |
| **Assumptions** | Which assumption turned out to be completely wrong? |
| **Dependencies** | What external system, vendor, or partner let us down? |
| **Market/context** | What changed in the world that made this irrelevant? |
| **Execution** | What did we fail to actually do? Where did we slip? |
| **Second-order** | What succeeded but caused something else to fail? |

Output: a raw list, no evaluation yet.

---

## Step 3 — Rank by impact × probability

Score each cause:
- **Impact** (1–3): How bad is this failure if it happens?
- **Probability** (1–3): How likely is it given our current plan?

Sort descending by `impact × probability`. Top 5 are the critical risks.

---

## Step 4 — Write the obituary (optional, high-stakes decisions)

Write a one-paragraph "obituary" for the project as if a journalist wrote it. Forces narrative coherence — reveals the single storyline that connects the top failure causes.

---

## Step 5 — Design preventions

For each top-ranked cause:
1. What early warning signal would appear before this failure materializes?
2. What specific change to the plan would prevent or reduce it?
3. Who owns the monitoring?

Output format:
```
Risk: [cause]
Signal: [early warning]
Prevention: [plan change]
Owner: [role/person]
```

---

## Step 6 — Decision

After working through the top risks:

```
**Pre-Mortem verdict for [project/decision]**
Critical risks: [top 2-3]
Plan changes recommended: [list]
Go/No-go: [proceed / modify / stop]
```

---

## Notes

- Separate generation from evaluation — don't judge causes during Step 2
- Silent individual generation first, then share, reduces anchoring bias
- Even if no plan changes result, the exercise calibrates the team's risk model
- Pair with `/brana:inversion` for maximum coverage (inversion finds what to avoid; pre-mortem finds what will go wrong)

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…