premortem

What this skill does

# Premortem

Imagine the plan already failed. Work backward to find why. Based on Gary Klein's HBR method — the "this is dead, explain how it died" frame produces more specific, honest failure modes than "what could go wrong?".

This breaks Claude's default agreeableness: instead of looking for reasons the plan works, you're explaining how it fell apart.

---

## When to run

**Good targets:** product/feature launches, pricing changes, hires, strategy pivots, partnerships, any commitment where being wrong is expensive.

**Bad targets:** vague ideas (help plan first), factual questions (just answer), draft feedback (that's editing), already-irreversible decisions.

If the user wants multiple perspectives on a current decision rather than failure analysis, suggest a different tool — premortems specifically simulate post-failure hindsight.

---

## Step 1 — Gather minimum context

You need three things before running:

1. **What is it?** — describable in one sentence
2. **Who is it for / who does it affect?**
3. **What does success look like?** — failure is success inverted

**Scan first, ask second.** Check the conversation, then run at most 2-3 `Glob`/`Read` calls for: `CLAUDE.md`, `memory/` folders, files the user referenced, related project briefs.

If something's missing, ask one focused question at a time. Don't interrogate — infer when you can.

---

## Step 2 — Set the frame explicitly

Once context is sufficient, say plainly:

> "It's 6 months from now. [The plan] has failed. We're looking back to understand what went wrong."

This framing is the mechanism. Don't skip it.

---

## Step 3 — Generate failure reasons

Produce a comprehensive list of genuine failure reasons. Each:
- Specific to this plan (not generic)
- Grounded in details the user provided
- A real threat (not a minor edge case)

State each in 1-2 sentences. The number is whatever's real — could be 3, could be 9. Don't pad. Don't truncate.

---

## Step 4 — Deep-dive agents in parallel

Spawn one agent per failure reason **in a single message with multiple Agent tool calls** so they run concurrently. Each agent investigates one failure independently.

**Agent prompt template** (substitute the bracketed sections before sending):

```
You are an investigator in a premortem. You've been assigned one specific failure to analyze.

THE PLAN:
[what it is, who it's for, success criteria, relevant workspace context]

FRAME: It is 6 months from now. This plan has failed.

YOUR ASSIGNED FAILURE: [the specific failure reason from step 3]

Write the story of how this specific failure played out. Be concrete. Use details from the plan.

Output (under 300 words total):

1. THE FAILURE STORY — 2-3 paragraph narrative of how it played out, naming specific moments where things went wrong.
2. THE UNDERLYING ASSUMPTION — the one thing the user took for granted that made this failure possible. One sentence.
3. EARLY WARNING SIGNS — 1-2 concrete, observable signals the user could watch for. Things you can see or measure, not vague feelings.

Be direct. Don't hedge. Don't sugarcoat.
```

---

## Step 5 — Synthesis

Read every deep-dive and produce:

1. **Most Likely Failure** — most probable given what you know. Why.
2. **Most Dangerous Failure** — worst damage if it happened, even if less likely.
3. **The Hidden Assumption** — the single biggest thing the user is taking for granted. Often where the real value lives.
4. **The Revised Plan** — concrete changes mapped to specific failure modes. Not "consider your pricing" — "test pricing at $X with 20 people before committing publicly."
5. **Pre-Launch Checklist** — 3-5 things to verify, test, or put in place before executing. Each prevents or detects one failure mode.

---

## Step 6 — Generate report

Save two files to the current working directory (confirm with the user if CWD looks wrong, e.g., a system path):

- `premortem-report-YYYYMMDD-HHMMSS.html` — visual report
- `premortem-transcript-YYYYMMDD-HHMMSS.md` — full transcript (gathered context, raw failure list, all agent deep-dives, synthesis)

Use a real timestamp from `date +%Y%m%d-%H%M%S`.

**HTML design:**
- Single self-contained file with inline CSS
- Dark background (e.g., `#0a0e1a`), clean typography, scannable
- Synthesis section (most likely / most dangerous / hidden assumption / revised plan / checklist) at the top — most users read this first
- One card per failure reason below: header, failure story, underlying assumption, early warning signs. Distinct accent colors per card.
- Footer with timestamp and what was premortemed

After writing, open the HTML report:

```
open premortem-report-YYYYMMDD-HHMMSS.html
```

(macOS. On Linux, use `xdg-open`.)

---

## Step 7 — Chat summary

In the chat, give a 3-sentence summary: most likely failure, hidden assumption, single most important plan revision. The HTML has the rest.

## Step 8 — Offer to chain

After the summary, offer one line: "Want me to convene the LLM council on the revised plan to pressure-test whether the revisions are right?" Skip the offer if the revised plan is trivially small or the user signaled closure.

---

## Principles

- **Always parallel.** All failure agents in one message. Sequential leaks earlier reasoning into later analysis.
- **Always set the frame.** "Already failed, explain why" is the psychological mechanism. Without it you get polite risk assessment.
- **Comprehensive, not padded.** Find every real failure. Don't stop at 3 if there are 7. Don't force 7 if there are 3.
- **The synthesis is the product.** Most users skim the cards and read the synthesis. Make it specific and actionable.
- **Don't sugarcoat.** Tell the user what they don't want to hear before reality does.
- **Concrete revisions only.** Every revised-plan item should be something the user can do this week.
- **Respect the context threshold.** One more question beats a generic premortem.