premortem

Premortem Skill

Overview

Premortem is Gary Klein's prospective-hindsight method, validated by Wharton and Cornell research: instead of asking "what could go wrong," assume the decision has already failed and reconstruct causes of death by working backward. The mental shift from hypothesis to fact dramatically expands the failure-cause space — people surface problems they would otherwise suppress to avoid looking negative.

This skill operationalizes that method as seven explicit phases:

1. Trigger & decision-type detection — confirm the trigger is valid, detect which domain (business, strategy, technical, personal) applies, load the appropriate reference file.
2. Context-gathering gate — collect three baseline minimums plus type-specific additions; establish the time horizon.
3. Framing — deliver the mandatory temporal frame statement that locks the mental model into failure-as-fact.
4. Raw premortem — generate N cause titles (dynamic, not padded to a round number).
5. Deep-dive per cause — narrative failure story, hidden assumption, and early warning signals per cause; parallel subagents where available, sequential fallback otherwise.
6. Synthesis — five-section fixed template: most likely failure, most dangerous failure, hidden assumption, revised plan, pre-launch checklist.
7. Persistence — save the output as Markdown, HTML, or chat-only at the user's choice.

The output of a complete run is a five-section synthesis (Phase 6) plus, optionally, the full Markdown or HTML report (Phase 7). The synthesis is self-contained and actionable without the supporting deep-dive text.

Phase 1: Trigger & decision-type detection

Triggers

This skill activates on any of the following:

• Slash command: /premortem
• Terms: premortem, pre-mortem, премортем, пред-мортем
• Direct phrases: what could go wrong, stress-test this plan, kill scenarios, что может пойти не так, проверь решение, прогони премортем

Before proceeding past trigger, verify that the decision is (a) not yet committed, (b) high-stakes (significant cost of error), and (c) concrete (a specific commitment, not a vague idea). If any condition fails, decline and explain which condition isn't met.

Decision-type detection

Scan the conversation context for signals and route to the appropriate reference file:

Signals in conversation context	Reference file
price, hire, launch, campaign, ICP, retention, CAC	references/business.md
pivot, M&A, fundraising, market entry, partnership, model validation	references/strategy.md
architecture, stack, migration, refactor, framework, ORM, DB, microservice	references/technical.md
relocation, career, relationship, purchase, education, identity	references/life.md (GATED)

If signals span multiple categories, ask one explicit clarifying question via AskUserQuestion (in Claude Code) or plain text (in other harnesses). Do not auto-route on ambiguous cases.

life.md second gate

Even when life-domain signals match, deliver this confirmation before loading life.md:

"This appears to be a personal decision. Confirm you want me to load life.md and run a premortem on it (not a professional decision)?"

Default to declining if the user does not give explicit consent. Do not proceed with life.md on ambiguous or implicit approval.

Phase 2: Context-gathering gate

Before delivering the framing statement, collect the three baseline minimums and any type-specific additions from the loaded reference file. Do not proceed to Phase 3 until all required context is present.

Three baseline minimums

1. What exactly — a concrete commitment, not "thinking about X". The user must be able to state it as a specific action: "launch feature Y at price Z on date W", not "we're considering a launch".
2. For whom — the target audience or stakeholders who will determine whether this decision succeeds or fails.
3. Success criteria — measurable. "Users like it" is not a criterion. "30-day retention above 40% within 3 months" is.

Type-specific additions

After loading the reference file, read its ## Context-gathering additions section and collect those additional inputs before proceeding. Each reference file defines what's required for its domain (e.g., technical.md requires rollback path and observability; strategy.md requires what is irreversible and alternative use of capital).

Time horizon

Auto-suggest the time horizon from the loaded reference file's ## Default time horizons section. State the suggestion explicitly and let the user override it before continuing.

One question at a time

Resolve missing minimums one question at a time. Do not present a questionnaire. Ask the most blocking question, wait for the answer, then ask the next if still needed. Three questions max before proceeding with reasonable inference and flagging the gaps.

Phase 3: Framing

The framing statement is mandatory and must be delivered verbatim before deep-dive:

"It's {today + horizon}. The {decision} has failed. This is fact. We are not assessing risk — we are reconstructing causes of death by working backward."

Without this framing, the analysis drifts back into polite risk assessment.

Substitute {today + horizon} with the actual projected date (e.g., "November 2026") and {decision} with the concrete commitment the user stated in Phase 2. Do not paraphrase the frame — deliver it as a declaration, not a question. After delivering the frame, proceed directly to Phase 4.

Phase 4: Raw premortem

Generate failure cause titles — one line each, no elaboration yet.

The count is dynamic: generate as many causes as genuinely surface from the framing and context. Typical range is 3-8. Do not pad to a round number. Do not restate the same cause under different names.

Format: numbered list, one cause per line, present-tense noun phrase (e.g., "Pricing mismatch with target segment", "Dependency on a single distribution channel", "Regulatory approval delayed past runway").

After listing the causes, state the count explicitly: "I've identified N failure causes." Then pause and proceed to Phase 5. Do not explain or defend individual causes at this stage — that is Phase 5's job.

Phase 5: Deep-dive per cause (graceful degradation)

Produce a deep-dive for every cause identified in Phase 4. Environment determines execution path.

Environment detection

Condition	Path
Task tool available (Claude Code, Cursor with agents)	Parallel subagents — one per cause
Task tool unavailable (Codex CLI, Claude.ai, plain chat)	Sequential single-context — one cause at a time

Subagent path (Task tool available)

Load references/subagent-prompt.md. Dispatch one Task per cause in parallel, passing the subagent prompt and the specific cause title as arguments. Collect all results before proceeding to Phase 6.

Sequential path (Task tool unavailable)

Iterate through each cause within the same context. Before each cause, re-state the framing:

"It's {projected date}. The {decision} has failed. Cause under analysis: {cause title}."

Separate causes with a --- divider. The restatement prevents context bleed-over where details from one cause contaminate the next.

Output per cause (both paths)

Each cause produces:

• Failure story — 2-3 paragraphs, past tense, concrete ("We launched in March. By May, churn was 38%..."). No hedging. Write as if reconstructing fact.
• Hidden assumption — one sentence, the unverified premise that made this cause invisible during planning.
• Early warning signals — 1-2 observable, specific signals that would have appeared 30-60 days before failure ("Pilot NPS below 30 at week 4", "Three enterprise pilots ghost after kickoff call").

Max 300 words per cause. Enforce the cap — depth over breadth.

Phase 6: Synthesis

After all deep-dives are complete, produce the synthesis in exactly five sections, in this order, under this heading structure:

1. Most likely failure — which cause is most probable and why, in one short paragraph. Name the cause explicitly.
2. Most dangerous failure — which cause is irreversibly destructive (may differ from most likely). Irreversibility is the key criterion: financial loss that can be recovered is not as dangerous as reputational damage, team dissolution, or legal liability that cannot be undone.
3. Hidden assumption — the unifying unverified premise that runs across the majority of causes. This is not a per-cause assumption (those are in Phase 5) — it is the one thing the whole plan is silently betting on.
4. Revised plan — concrete actions, not gestures. Write as specific commitments: "Test $47 price point with 20 customers before committing to packaging" not "think about pricing". Each action must be attributable to a specific cause from Phase 4/5.
5. Pre-launch checklist — actionable, verifiable items with explicit success criteria. Each item must be checkable by a third party: "Pilot NPS ≥ 40 across 3 enterprise accounts before GA launch" is checkable. "Validate product-market fit" is not.

The synthesis is the primary deliverable. Write it to stand alone — a reader who skips Phases 4-5 must still be able to act on Phase 6 output.

Phase 7: Persistence

After Phase 6 synthesis is delivered, offer the user three save options.

Save format prompt

In Claude Code: use AskUserQuestion with these three options. In Codex CLI, Cursor, or plain chat: present as a numbered text list and ask the user to reply with the number.

Options:

1. Markdown report — saved to ./premortem-reports/{YYYY-MM-DD}-{slug}.md
2. HTML report — saved to ./premortem-reports/{YYYY-MM-DD}-{slug}.html
3. Chat only — no file saved

{YYYY-MM-DD} is today's date. {slug} is a 3-5 word kebab-case summary of the decision (e.g., saas-pricing-launch, market-entry-latam).

Markdown report format

Frontmatter:

---
date: {YYYY-MM-DD}
decision_type: {business|strategy|technical|life}
horizon: {time horizon stated in Phase 2}
original_decision: "{exact commitment the user stated in Phase 2}"
---

Body: full transcript of all 7 phases in order, followed by the Phase 6 synthesis as a standalone section. Use the phase headings from this skill as section headings.

HTML report format

Load assets/report-template.html. Substitute all {{placeholder}} tokens with the corresponding values from this session (date, decision_type, horizon, original_decision, synthesis content, cause list). Write the result to the output path. Do not modify the template file.

Optional: time-based reminders

After saving (or if the user chose chat-only), offer:

"Would you like 30/60/90-day text reminders to check the early warning signals against reality?"

If yes, generate three plaintext reminder messages — one for each interval — that the user can copy into their calendar or task manager. Each reminder lists the early warning signals from Phase 5, the decision, and the projected date. v1 is text only: no calendar API integration, no automated scheduling.

Anti-sycophancy guardrails

These rules apply throughout the run, especially during Phase 5 (deep-dive) and Phase 6 (synthesis):

1. Don't sugar-coat. If the plan is bad, say so directly. "There are nuances" is evasion.
2. Don't pad failure modes for completeness. Three strong causes beat five with a weak pair.
3. Don't soften hidden assumptions. If the assumption is bullshit, name it bullshit. Technical use of the word, not insult.
4. Revised plan equals concrete actions, not gestures. "Think about pricing" is not a plan. "Test $47 with 20 customers before committing to $297" is a plan.
5. If the whole decision is bad, the synthesis can say "kill the plan." That is a valid premortem outcome.
6. User's emotional investment is irrelevant. If the user is clearly invested, the method stays cold. The method only works if it stays cold.

Known failure modes of this skill

When you catch yourself in any of these, correct course:

• Generic failures ("plan may fail due to bad PMF"): if a cause sounds template-like, rewrite it concretely against the actual context with real names, numbers, and dates from the conversation.
• All failures point to same root cause: collapse them into one cause rather than five disguises of the same problem.
• Synthesis contradicts deep-dive: re-check. If deep-dive flagged #3 as most likely but synthesis crowned #1, something is wrong — fix the synthesis or the deep-dive.
• Unverifiable checklist items: "improve marketing" can't be checked. Rewrite as "X writes 3 customer interview summaries by Y date."
• User shapes input toward desired output: if the user starts dismissing warning signals as the analysis surfaces them, flag it: "you just dismissed signal #2; that is the main failure mode."

Negative scope (when this skill does NOT trigger)

If the user's message matches one of these patterns, do not run the premortem. Suggest the appropriate alternative or ask them to clarify what's high-stakes about the decision.

• Informational questions about premortem method itself ("what is premortem?", "how does Klein's method work?")
• Brainstorming without a committed decision ("какие у нас идеи для X")
• Code review, debugging, or technical questions without a high-stakes-decision marker
• Emotional support requests — this is the wrong tool
• Postmortem of decisions already executed
• Low-stakes decisions (blog title, color choice, etc.)

If the gate refuses, the response should be short, direct, and offer the next step (a different skill or a clarifying question). Don't lecture about scope.

Empty premortem case

If Phase 2 (context-gathering) reveals the decision is genuinely reversible with low cost, exit cleanly:

"This isn't high-stakes — premortem is overkill here. Ship and iterate."

This is a successful skip, not a failure.