/swing-mortem

name: swing-mortem
description: Prospective failure analysis using Gary Klein's pre-mortem technique. Assumes complete failure, works backward to identify risks, leading indicators, and circuit breakers. Counters optimism bias by forcing systematic exploration of failure modes before they materialize. Use for project plans, architecture decisions, technology adoption, business strategy, or feature launches. Triggers on "리스크", "위험", "실패하면", "swing-mortem", "뭐가 잘못될 수 있어", "risk", "what could go wrong", "걱정되는 점", "failure modes", "리스크 분석", "위험 분석".
argument-hint: "[plan, decision, or initiative to stress-test for future failure]"
allowed-tools: Read, Grep, Glob, Bash, Agent

Pre-Mortem

Prospective failure analysis that defeats optimism bias by assuming failure first, then working backward to surface risks, early warnings, and escape hatches.

**Based on Gary Klein's pre-mortem technique:** Instead of asking "will this work?" (which triggers optimism bias), this skill forces the question: "It's 6 months from now and this has completely failed. What went wrong?"

**Key distinction from swing-review:**

• `swing-review` examines the **CURRENT** state — "what's wrong NOW?"
• `swing-mortem` examines the **FUTURE** — "what will go wrong LATER?"
• Adversarial review finds existing flaws. Pre-mortem anticipates flaws that don't exist yet.

Rules (Absolute)

1. **Never produce generic risks.** Every failure scenario must name specific technologies, quantities, timelines, or conditions. "The database might not scale" is banned. "PostgreSQL connection pool exhaustion at >2,000 concurrent users due to long-running analytical queries holding connections for 30s+" is acceptable. 2. **Exactly 5 scenarios across 5 categories.** One Technical, one Organizational, one External, one Temporal, one Assumption. No category may be skipped, no category may have more than one scenario. 3. **Leading indicators must be observable and measurable.** "Watch out for problems" is banned. Every indicator must specify what to measure, what threshold signals danger, and where to observe it. 4. **Circuit breakers must include a specific trigger condition.** "If things go wrong" is banned. Every trigger must be a measurable condition with a concrete threshold. 5. **The swing-mortem summary is MANDATORY.** It is the BLUF of the analysis. It must appear at the end and synthesize the highest risk, its leading indicator, and its escape hatch in one paragraph. 6. **Assume complete failure.** Not partial, not "underperformance." The premise is total failure. This extreme framing is what forces creative risk identification — do not soften it. 7. **Specificity over coverage.** One deeply analyzed, plausible failure scenario per category is worth more than five shallow ones. Depth beats breadth.

Process

Execute these 6 phases sequentially. Do NOT skip phases.

Phase 1: Set the Failure Frame

Establish the temporal and contextual frame before any analysis.

FAILURE FRAME
─────────────
Subject: [what is being analyzed — plan, decision, architecture, launch]
Timeframe: [when failure is discovered — default 6 months, adjust to context]
Failure statement: "It is [timeframe] from now. [Subject] has failed completely.
Not partially underperformed — completely failed. The team is conducting a
post-mortem. What went wrong?"

If the subject is ambiguous or too broad, **ask one clarifying question** before proceeding. "Analyze our project" is too vague. "Analyze our migration from MongoDB to PostgreSQL for the user service" is actionable.

Before generating scenarios, gather context:

• If code/architecture exists, **read relevant files** to ground scenarios in reality
• If a project plan exists, **examine timelines and dependencies**
• If prior decisions are documented, **review the rationale and constraints**

Do not generate scenarios from imagination alone when concrete artifacts are available.

Phase 2: Failure Scenario Generation

Generate exactly 5 failure scenarios, one per category. Each scenario must be a specific, plausible narrative — not a generic risk label.

Category 1: Technical

The technology didn't work as expected. Name the specific technology, the specific failure mode, and the specific conditions under which it failed.

Category 2: Organizational

Team, process, or communication broke down. Name the specific team dynamics, handoff points, or process gaps that caused failure.

Category 3: External

Market shifted, competitor moved, regulation changed, or a dependency broke. Name the specific external force and its specific impact.

Category 4: Temporal

Timeline was wrong. Name what took longer (or what window was missed) and by how much, with the specific cascading consequence.

Category 5: Assumption

A core assumption turned out to be false. Name the specific assumption, why it seemed reasonable at the time, and what reality turned out to be.

Format each scenario as:

SCENARIO [N]: [Category] — [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

What happened:
[2-4 sentence specific narrative of how this failure unfolded]

Why it was plausible:
[1-2 sentences on why this wasn't obvious beforehand]

Concrete consequence:
[Specific, measurable impact — revenue lost, users affected, time wasted, data compromised]

Phase 3: Likelihood x Impact Matrix

Rate each scenario and determine priority:

RISK MATRIX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| # | Category       | Scenario             | Likelihood | Impact       | Priority |
|---|----------------|----------------------|------------|--------------|----------|
| 1 | Technical      | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 2 | Organizational | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 3 | External       | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 4 | Temporal       | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |