From premortem-skill
Run a Gary Klein-style premortem on a high-stakes decision — assume the plan has already failed and reconstruct causes of death by working backward. Use when the user explicitly invokes /premortem, or says "премортем", "пред-мортем", "premortem", "pre-mortem", "что может пойти не так", "проверь решение", "прогони премортем", "what could go wrong", "stress-test this plan", or "kill scenarios". The decision must be (a) not yet committed, (b) high-stakes (significant cost of error), and (c) concrete (a specific commitment, not a vague idea). Does NOT trigger for: informational questions about the method itself, brainstorming without a committed decision, code review or debugging, postmortem of past decisions, emotional support, or low-stakes choices. Does not invoke other skills and is not invoked from other skills.
How this skill is triggered — by the user, by Claude, or both
Slash command
/premortem-skill:premortemThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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:
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.
This skill activates on any of the following:
/premortempremortem, pre-mortem, премортем, пред-мортем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.
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.
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.
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.
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).
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.
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.
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.
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.
Produce a deep-dive for every cause identified in Phase 4. Environment determines execution path.
| 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 |
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.
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.
Each cause produces:
Max 300 words per cause. Enforce the cap — depth over breadth.
After all deep-dives are complete, produce the synthesis in exactly five sections, in this order, under this heading structure:
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.
After Phase 6 synthesis is delivered, offer the user three save options.
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:
./premortem-reports/{YYYY-MM-DD}-{slug}.md./premortem-reports/{YYYY-MM-DD}-{slug}.html{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).
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.
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.
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.
These rules apply throughout the run, especially during Phase 5 (deep-dive) and Phase 6 (synthesis):
When you catch yourself in any of these, correct course:
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.
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.
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.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub procoders/premortem-skill --plugin premortem-skill