Premortem — Kill Bad Plans Before They Kill You

Core idea: Instead of asking "will this work?" → imagine it already failed 6 months from now, then explain why. This is Kahneman's single most valuable decision tool. It breaks the AI's default agreeableness and your own optimism bias.

Philosophy: Denk dir Dinge zuende. Sei kritisch mit dir selbst. The premortem is not about being pessimistic — it's about being honest before reality forces honesty on you.

Two Modes

Quick Premortem (!premortem / !pm) — 30 seconds

For small-to-medium decisions during coding. 3 questions + quick L/I calibration.

1. What's the most likely way this fails? — Rate L (1-5) + I (1-5)
2. What's the worst-case failure? — Even if unlikely, what's the damage?
3. What's one thing you should verify right now? — Checkable in this session

Automatic L/I: For the #1 failure, assign L × I and show the zone. L=4 I=3 → 12 🟠 Needs mitigation

No ceremony. ~12-16 lines, 30 seconds.

Full Premortem (!premortem full / !pm full) — 2-3 minutes

For high-stakes decisions: architecture choices, deploys, major refactors, feature launches. Runs all 4 core features:

1. Base Rates — Reference real failure statistics for this type of decision
2. Bias Circuit-Breaker — Systematic check for Sycophancy, Optimism, Availability, Anchoring
3. L/I Scoring — Likelihood × Impact scoring (1-5) for each failure mode
4. Commitment — Concrete next action with a date

Context Auto-Detection

Before running, determine what the user is planning:

Git Context (if in a repo)

• git log --oneline -3 → What's the current branch doing?
• git diff --stat HEAD~1 → How many files changed? What type of work?
• git branch --show-current → Feature branch? Fix branch? Main?
• Keywords: If commits mention "refactor", "migrate", "rewrite", "restructure" → auto-suggest !pm

Conversation Context

• What was the user's last message? Are they describing a plan?
• Any architecture decisions, config changes, or dependency additions?
• Are they about to merge/deploy? High-risk?

If unclear after scanning, ask ONE question: "Was genau planst du gerade?" Don't ask more than that.

Quick Premortem Flow

When the user says !premortem or any immediate trigger:

### Premortem 🔪

Plan: [one-line summary of what you detected they're doing]

#### 1. Most Likely Failure
[specific, grounded in their actual context. Not generic.]
L=? I=? → L×I=? [zone]

#### 2. Worst-Case Failure
[the one that would do real damage, even if less likely]
L=? I=? → L×I=? [zone]

#### 3. Verify Now
[one concrete thing they can check right now, in this session]
→ [actual command or check they can run]

That's it. Total output: ~12-16 lines. Keep moving.

Full Premortem Flow

When the user says !premortem full:

Step 1: Set the Frame

🔪 FULL PREMORTEM — 6 months from now, this has FAILED.

Plan: [one-line summary]

Step 2: Failure Generation

Run all 4 features in parallel (spawn sub-agents or run as structured analysis). Produce:

## Failure Modes

[numbered list, each 1-2 sentences, specific to THIS plan]

Step 3: The 4 Features (integrated output)

## Risk Assessment

| # | Failure Mode | L | I | L×I | Mitigation |
|---|-------------|---|---|-----|------------|
| 1 | [mode]     | 4 | 5 | 20  | [concrete] |
| 2 | [mode]     | 3 | 4 | 12  | [concrete] |
...

Step 4: Base Rates Check

For each failure mode, ask: "What class of decision is this, and what does the base rate say?"

Source: references/base-rates.md. Quick reference:

• Software project → 70% timeline overshoot
• Refactoring → 64% exceed 50%+ of estimate
• Product launch → 70-95% failure rate
• Feature without user research → 64% fail

Example: Your "2-week estimate" → base rate says 3-4 weeks minimum.

Step 5: Bias Circuit-Breaker

After generating failures, run these checks (source: references/bias-circuit-breaker.md):

• Sycophancy check: Am I being too nice? Would I say this to a stranger?
• Optimism check: What's the inside view vs. outside view timeline?
• Availability check: Am I anchoring on the last thing I built/saw?
• Anchoring check: Is my estimate anchored to an arbitrary starting point?

If any check triggers, note it in the output:

⚠️ Bias alert: Optimism bias detected. Inside view says 2 weeks. Outside view (similar projects) says 3-4 weeks.

Step 6: Commitment

## Commitment

[ONE concrete action] by [DATE].

Example: "Test pricing at $47 with 10 users by Friday" — NOT "consider testing pricing."

Output Format (Full)

🔪 PREMORTEM REPORT

## Failure Modes (N found)
1. [failure 1]
2. [failure 2]
...

## Risk Matrix
| # | Failure | L | I | L×I | Mitigation |
|---|--------|---|---|-----|------------|
...

## Bias Check
[any triggered biases with explanation]

## Commitment
[action] by [date]

→ Top priority: [the ONE thing to fix first]

The 4 Core Features (always active in Full mode)

1. Base Rates

Every failure mode is evaluated against real statistics. See references/base-rates.md. Key data points:

2. Bias Circuit-Breaker

Run AFTER generating failures (not before — don't filter yourself). Check for:

• Sycophancy: Am I being too agreeable? Rephrase the failure in the harshest honest terms.
• Optimism: Inside view vs. outside view. What would someone who's done this 10 times say?
• Availability: Is this failure mode from the last thing I read/built, or is it genuinely relevant?
• Anchoring: Did I start from an arbitrary number and insufficiently adjust?
• Scope Creep (Bonus): Is the plan bounded? What's explicitly NOT included?

See references/bias-circuit-breaker.md for detailed protocols.

3. L/I Scoring

For every failure mode:

• Likelihood (L): 1 = <5% chance, 2 = 5-20%, 3 = 20-50%, 4 = 50-80%, 5 = >80%
• Impact (I): 1 = minor annoyance, 2 = some rework, 3 = delay/reputation hit, 4 = major loss, 5 = project-killing
• L×I: Multiply. Focus on scores ≥12.

See references/li-scoring.md for scoring anchors.

4. Commitment

Every full premortem ends with ONE concrete commitment:

• Format: "[Specific action] by [Date]"
• NOT: "Consider X" or "Think about Y" or "Look into Z"
• Examples: "Write integration tests for the payment flow by Thursday" ✓ — "Consider testing more" ✗

See references/commitment.md for the commitment protocol.

When to Use

Good targets:

• Architecture decision (monolith vs. microservice, library choice, DB schema design)
• Before a big refactor ("I'm going to rewrite the auth module")
• Before deploying to production
• Before committing to a timeline or estimate
• Before a major purchase or SaaS decision
• When you're too confident about a plan (that's the danger signal)

Bad targets:

• One-line changes or trivial fixes (just do it)
• Questions with a factual answer (just answer it)
• Problems you can't change anymore (premortem requires agency)
• When you're already in crisis mode (premortem is PRE, not DURING)

Auto-detection: If the user describes a plan spanning 3+ files, an architecture decision, or uses words like "refactor," "rewrite," "migrate," "restructure" — suggest a quick premortem: "Want me to premortem this before you start?"

Anti-Patterns

• Generic failures: "The code might have bugs" is useless. Be specific to THIS plan.
• Going through the motions: A