Decision Pre-Mortem

---
name: decision-pre-mortem
description: >-
  Runs a structured pre-mortem on a decision before you commit — surfaces the
  assumptions baked into the plan, works backward from a hypothetical failure
  to find what would actually sink it, flags the questions nobody has asked
  out loud yet, and returns a Go / Hold / Go with conditions verdict with
  the reasoning behind it.
  Use whenever someone is about to commit to a decision that's expensive or
  hard to reverse (opening an office, a key hire, a vendor contract, a pricing
  change, a partnership, a capex approval) and wants a pressure test first.
  Triggers include "run a pre-mortem", "pre-mortem this", "what could go wrong
  with this plan", "pressure-test this decision", "should we do this", "what
  am I missing here", or uploading a plan/memo and asking for a gut check
  before it goes out.
metadata:
  author: "Aleph - getaleph.com"
  version: "1.0.0"
---

# Decision Pre-Mortem

## What this skill does

Most decisions get reviewed for whether the math works. Few get reviewed for
whether the *thinking* holds up. This skill runs the second review: the same
structured pass, on every decision, so nothing hard to reverse ships on vibes
alone.

The technique is Gary Klein's **prospective hindsight** ("Performing a
Project Premortem," *Harvard Business Review*, 2007): imagine the decision
has already failed, then work backward for the most plausible reasons why —
before it's real and expensive to admit. The output is always the same shape:
the assumptions the plan is quietly standing on, the failure stories that are
actually plausible (not just any failure story), the questions nobody's
asked, and a verdict — Go, Hold, or Go with conditions — with the reasoning
attached.

## When to use it

- Before a decision that's expensive or hard to reverse: an office lease, a
  key hire, a vendor contract, a pricing change, a partnership, a capex
  approval.
- Before a memo or proposal goes to leadership or the board.
- Any time the honest answer to "have we pressure-tested this?" is no.

## Inputs

Accept the decision in whatever form it exists:

- A memo, proposal, or plan (uploaded file or pasted text)
- A few paragraphs describing the call, if nothing's written yet
- Optional supporting material: the model behind it, deal terms, a proposal

If the decision isn't clearly stated, ask one clarifying question — what's
being decided and by when — rather than guessing.

## Workflow

1. **Extract the decision and its assumptions** — read
   `references/methodology.md` and pull out every assumption the plan is
   built on, explicit and implicit. Classify each as **load-bearing** (if
   false, the plan fails) or **decorative** (doesn't change the outcome
   either way). Do not skip the implicit ones — they're usually where the
   real risk hides.
2. **Run the pre-mortem** — apply prospective hindsight per
   `references/methodology.md`: assume it's a year from now and this failed,
   then work backward for the two or three most *plausible* failure stories,
   not an exhaustive list of everything that could theoretically go wrong.
   Rank by likelihood and by damage if it happens.
3. **Surface the unasked questions** — run the five-question checklist in
   `references/methodology.md` (reversibility, base rate, capacity,
   dependency, opportunity cost) against the plan. For each, either answer it
   from what's in the plan or flag it as genuinely unanswered.
4. **Return the verdict** — assemble everything into the exact structure in
   `references/output-template.md`. The verdict is always one of Go / Hold /
   Go with conditions, and it always comes with the specific reasoning and
   (if not a clean Go) the specific conditions that would change it.

## The methodology

The full framework — the assumption taxonomy, the prospective-hindsight
technique, and the five-question checklist — lives in
`references/methodology.md`. Treat it as the standard, not a suggestion; it's
the reason this is a repeatable skill and not a one-off opinion.

## Output format

Always return the verdict in the exact structure defined in
`references/output-template.md`. Same shape every run — that consistency is
the point. A decision reviewed twice, before and after changes, should
produce two verdicts you can actually compare.

## A note on scope

This skill pressure-tests the *thinking* behind a decision before it's
committed. It doesn't verify the underlying numbers are correct — if the plan
depends on a financial model, treat the model's arithmetic as a separate
question — that's a model-audit job, and the `model-sanity-checker` skill
from the same library covers it. And it stops at the decision, not the
aftermath — once you're committed, tracking whether reality matches the
plan is a different, ongoing job.

# Pre-Mortem Methodology

Apply all three parts below, in order, to every decision. This is the
skill's core expertise — the reason a pre-mortem run through this framework
is worth more than "what could go wrong?" typed into a chat window.

## 1. Assumption extraction

Every plan is a tower of assumptions, most of them never written down. Find
them before you test them.

- **Explicit assumptions** — stated directly in the plan ("we'll hire 8
  people," "the lease is 3 years"). Easy to find; extract them first.
- **Implicit assumptions** — never stated, but required for the plan to
  work as described. The most common ones to hunt for:
  - **Ramp/productivity assumptions** — does the plan assume people, deals,
    or systems perform at full capacity immediately, with no ramp?
  - **Timing assumptions** — does the plan assume things happen in parallel
    that usually happen in sequence (hiring while leasing while onboarding)?
  - **Capacity assumptions** — does the plan assume the team executing it
    has slack, when they may not?
  - **Causal assumptions** — does the plan assume X causes Y (presence
    causes close rate, price causes churn) without evidence, just narrative?
- **Load-bearing vs. decorative** — for each assumption, ask: if this turns
  out false, does the plan fail, or does it just look a little different?
  Load-bearing assumptions are where the pre-mortem in step 2 should focus.
  Decorative ones can be noted and set aside.

## 2. Prospective hindsight (the pre-mortem proper)

From Gary Klein, "Performing a Project Premortem" (*Harvard Business
Review*, September 2007). The technique: **assume the decision has already
failed**, a year from now, and work backward to explain why. This works
because it's much easier to generate honest reasons for a failure everyone
is imagining together than to raise doubts about a plan people have already
committed to.

- Generate **the two or three most plausible failure stories** — not a
  brainstormed list of every conceivable disaster. A pre-mortem that produces
  twenty far-fetched risks is as useless as one that produces zero. Anchor
  each story in a load-bearing assumption from step 1.
- For each failure story, state:
  - **What happened** — the concrete way it went wrong.
  - **Why it was plausible** — which assumption broke, and why that
    assumption was fragile in the first place.
  - **The early warning sign** — what you'd have seen 60-90 days in, if this
    was happening, before it became irreversible.
- Rank the failure stories by a combination of **likelihood** and
  **damage if it happens**. A likely-but-survivable outcome and a
  rare-but-fatal one both deserve a line; a rare-and-survivable one usually
  doesn't make the list.

## 3. The five unasked questions

Most planning documents implicitly answer "does the math work?" and stop.
Run every decision through these five questions. If the plan already
answers one, say so. If it doesn't, that silence is itself a finding.

1. **Reversibility** — If this goes wrong, how do we undo it, and what does
   undoing it cost? A decision with a cheap exit deserves a lighter pre-mortem
   than one that's a one-way door.
2. **Base rate** — How often do plans that look like this one actually hit
   their stated numbers, in general? A plan can be well-reasoned and still be
   fighting a bad base rate.
3. **Capacity** — Do the people expected to execute this have the actual
   time and attention to do it well, on top of what they're already doing?
   Budget approval is not capacity.
4. **Dependency** — What does this decision quietly assume will also be true
   somewhere else in the business (another team's hiring, another system's
   readiness, a customer's behavior) that nobody has actually confirmed?
5. **Opportunity cost** — What does saying yes to this mean saying no to?
   Every commitment of money, time, or people is a decision not to spend
   those things elsewhere.

## Calibration

- Do not manufacture risk where none is plausible. A well-scoped, reversible,
  well-capitalized decision can and should score close to a clean Go.
- Do not soften a real finding to be polite. The value of this skill is
  catching the blind spot while it's still cheap to fix — that only works if
  the findings are honest.
- Always tie findings back to a specific line, number, or sentence in the
  plan. A pre-mortem finding with no anchor in the actual document is a
  generic opinion, not a review.

# Pre-Mortem Verdict — Output Format

Always produce the output in exactly this structure and order. The
consistency is the point: a decision reviewed twice — before and after
changes — should yield two verdicts you can directly compare.

---

## 🎯 Decision Pre-Mortem

**Decision:** {one line — what's being decided, and the stated deadline}
**Overall verdict:** {one of — 🟢 Go · 🟡 Go with conditions · 🔴 Hold} —
followed by one sentence of rationale.

---

### Assumptions this plan is standing on

| Assumption | Type | Load-bearing? | Note |
|---|---|---|---|
| {assumption} | {Explicit / Implicit} | {Yes / No} | {one line — where it shows up in the plan, or that it's unstated} |

List every assumption found in step 1, in the order of how much weight
they're carrying. Load-bearing implicit assumptions belong at the top.

---

### If this fails, here's why — a year from now

For each of the 2-3 most plausible failure stories:

**{Failure story title, stated plainly}**
- **What happened:** {the concrete failure}
- **Why it was plausible:** {which assumption broke, and why it was fragile}
- **Early warning sign:** {what you'd see 60-90 days in}
- **Likelihood / damage:** {High / Medium / Low each}

If the decision is genuinely low-risk, two Low-likelihood / Low-damage
stories are a valid result — do not manufacture risk to fill the section.

---

### The questions nobody's asked

Run all five. Mark each as **Answered** (with the plan's answer) or
**Unanswered** (flagged as a real gap).

- **Reversibility** — {answer, or "Unanswered — no exit terms stated"}
- **Base rate** — {answer, or "Unanswered — no comparable referenced"}
- **Capacity** — {answer, or "Unanswered — execution owner not named"}
- **Dependency** — {answer, or "Unanswered — depends on X, not confirmed"}
- **Opportunity cost** — {answer, or "Unanswered — not addressed in the plan"}

---

### 🔧 What would move this to a Go

Only if the verdict isn't a clean Go. A numbered list, in priority order —
the specific conditions, information, or changes that would resolve the
biggest risks above.

1. {…}
2. {…}
3. {…}

---

*Re-run this after the plan changes — same framework, so you can see exactly
what got resolved and what didn't.*

Only if the verdict isn't a clean Go, add: *Want help drafting the missing
pieces above?*

WHAT THIS FILE IS
=================
decision-pre-mortem.skill — Runs a structured pre-mortem on a big decision and returns a Go / Hold / Go with conditions verdict.

A .skill file is Anthropic's packaging format for Claude Skills. It is a
standard ZIP archive, nothing more. If you are reading this in a text
editor, you are looking at the raw bytes of that archive — this build is
intentionally uncompressed so the contents stay human-readable.

LOOK INSIDE YOURSELF
====================
Rename the file from .skill to .zip and extract it, or run:  unzip decision-pre-mortem.skill
Every file inside is plain-text markdown — the instructions Claude reads.
There is no executable code in this package.

WHAT'S INSIDE
=============
  SKILL.md
  references/methodology.md
  references/output-template.md
  README.txt (this file)

HOW TO USE IT
=============
Upload this file as-is to Claude: Settings -> Skills -> Add.
Or add it in Claude Cowork or Claude Code.

From Aleph (getaleph.com), the FP&A platform.
The full guide: https://www.getaleph.com/claude-skills-library
Questions: marketing@getaleph.com