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 was used to attack our users via this app.")
• The target system — what code, service, or component the scenario is posed against. Confirm scope: which directories, which services, which boundaries? Pre-mortemers will read this code; out-of-scope code should be excluded.

Produce a written brief that pairs the scenario with the system scope. Pre-mortemers operate on this brief and have read access to the scoped code.

2. Validate the Input Is Concrete Enough to Fail Concretely

A pre-mortem on "we will improve quality" produces noise. A pre-mortem on "we will replace the auth service over six weeks" produces signal. The same applies to scenarios: "something bad happened" produces noise; "the prod DB was destroyed by a design defect" produces signal.

Plan mode — check:

• Is the deliverable named, not gestured at?
• Is the timeframe bounded?
• Are the dependencies visible?
• Is the success criterion something a third party could verify?

Scenario mode — check:

• Is the scenario specific (a named catastrophic outcome), not vague ("things went wrong")?
• Is the target system identified and scoped?
• Is the scenario mechanistically plausible against the system as described, even if hypothetical?

If the input fails its checks, say so plainly and offer the alternative:

• Plan mode: refine the plan first (/scope, /think-reframe).
• Scenario mode: refine the scenario into something mechanistically posable, or — if the user is asking about an actually-occurring failure rather than a hypothetical — redirect to /think-diagnose (causes of an observed phenomenon) or /think-reflect (learning from a resolved incident). Scenario-mode pre-mortem is for hypothetical catastrophes against running systems, not for incidents that have actually happened.

3. Choose Failure-Class Lenses

Pre-mortemers cover three categories of lens:

1. Standard lenses — the 11 prescribed failure classes below. Pick 4-7 that fit the target.
2. Ad-hoc target-specific lenses — 0-3 additional lenses the orchestrator names when the target has known domain-specific failure modes that don't fit the standard taxonomy.
3. first-principles lens — always runs. Looks for failure modes specific to this target that don't fit cleanly into any standard or ad-hoc lens. Catches what the prescribed taxonomy misses.

The orchestrator decides selection; the user does not pick.

In plan mode, standard-lens selection is driven by what the plan affords (technical, operational, estimation are usually present; team, adoption, dependency-and-environment are situational).

In scenario mode, standard-lens selection is partly fixed by the scenario itself — a zero-day exploit scenario has adversarial as its primary lens; a runaway-bill scenario has incentive and operational; a DB-destruction scenario has technical and reversibility. Pick lenses that the scenario