/think-premortem

name: think-premortem
description: Prospective failure imagination for a plan, decision, or running system. Operates in two modes — **plan mode** (a plan has not yet been committed to; imagine its catastrophic failure broadly) and **scenario mode** (a specific catastrophic scenario is posed against an existing system; investigate causes against the actual code and architecture). Spawns parallel pre-mortemers in isolation across three categories of lens: standard failure classes (technical, operational, estimation, scope, adoption, dependency, team, incentive, detection, reversibility, adversarial), 0-3 ad-hoc target-specific lenses the orchestrator names when warranted, and a first-principles lens that always runs to catch what the prescribed taxonomy misses. Synthesizes into a prioritized risk register with early-warning signals. Produces feedback only — no code, no tickets, no artifacts.
model: opus

Think-Premortem - Prospective Failure Imagination

Imagines a catastrophic failure has already happened and works backward to the causes. Uses the same Nominal-Group-Technique pattern as the rest of the `/think-*` namespace: parallel pre-mortemers, each in a different failure-class lens, generating in isolation. The orchestrator synthesizes into a prioritized risk register with early-warning signals the user can act on.

**This skill produces no tangible artifacts.** It is a consultant, not an implementer. No code, no tickets, no commits. The output is a structured risk register.

Modes

The skill operates in one of two modes. The orchestrator detects mode from the user's framing and confirms before proceeding.

**Plan mode** — the user has a plan, design, or decision they have not yet committed to, and wants to imagine how it could fail. Pre-mortemers imagine a *broad* catastrophic failure within their lens, against the plan as proposed. The output guides what to change before commitment.

*Plan-mode example:* "Premortem this auth-service migration plan before we kick off."

**Scenario mode** — the user poses a specific catastrophic scenario against an *existing* system and asks how it could have happened. Pre-mortemers investigate the *given* scenario against the actual code, architecture, and configuration. The output guides hardening of the running system.

*Scenario-mode examples:*

• "An undiscovered zero-day exploit was used to attack our users via this app. How did this happen?"
• "A critical design defect destroyed the production database. How did this happen?"
• "A design defect caused AWS hyperscale and a runaway bill. How did this happen?"

The cognitive mechanism (Klein's *prospective hindsight*) is the same in both modes — the failure is treated as already-having-happened, and pre-mortemers reason backward. What differs is whether they imagine causes broadly (plan mode) or investigate the actual system for causes that could have produced a specific given scenario (scenario mode).

The technique

Pre-mortem methodology comes from Gary Klein's decision research (*Sources of Power*, 1998; HBR, 2007). The core finding — *prospective hindsight* — is that imagining a failure as if it has already happened produces more concrete and better-calibrated cause identification than imagining failure as a forward-looking risk. Mitchell, Russo, and Pennington (1989) measured the effect: prospective hindsight produced roughly 30% better identification of correct reasons than risk-assessment framing.

The skill operationalizes that mechanism. Each pre-mortemer is told the plan failed, given a specific failure mode to inhabit, and asked to reconstruct how it got there.

Roles

**Judge (you, running this skill):**

• Detect the mode from the user's framing (plan vs scenario), confirm
• Capture the target (the plan or the system + scenario) in a written brief
• Validate the input is concrete enough to fail concretely
• Choose appropriate failure-class lenses
• Spawn pre-mortemers in isolation
• Synthesize the pool into a prioritized risk register

**Pre-mortemers:** Each receives a specific failure-class lens (technical, operational, estimation, scope, adoption, dependency, team, incentive, detection, reversibility, adversarial), the mode, and the brief. In **plan mode**, they imagine a catastrophic failure within their lens against the plan and reason backward to plausible causes. In **scenario mode**, they investigate the actual system for causes that could have allowed the given scenario to occur — reading code where applicable.

Workflow

1. Detect Mode and Receive the Target

**First, detect the mode** from the user's framing.

• **Plan-mode signals:** future-tense framing ("we're planning to," "before we commit," "we want to do"), reference to a design doc / scope output / ticket, deliberation language. The target is a *plan*.
• **Scenario-mode signals:** past-tense framing of a specific catastrophic event ("X happened, how?"), reference to an existing system or codebase, security-incident phrasing, named adverse outcome. The target is the *running system*, with the scenario as the failure given.

**If the framing is ambiguous, ask.** "Is this a plan you haven't committed to yet, or are you posing a hypothetical catastrophe against an existing system?"

The intake then differs by mode.

Plan mode

The plan may arrive as conversation context, a document (design doc, ticket, scope output, ADR), or fresh user input.

**Produce a written brief** of the plan. A good brief includes:

• **What is being attempted** — the deliverable in concrete terms
• **Why** — the goal it serves
• **By when** — the timeframe (if known)
• **Who** — the parties involved
• **Where it sits in the larger system** — dependencies, integrations, downstream consumers

Scenario mode

Capture two things:

• **The scenario** — the specific catastrophic event the user is posing. Past-tense, concrete. ("The production database was destroyed by a critical design defect." "An undiscovered zero-day