premortem
This tool identifies potential project risks by analyzing plans and designs using the Shreyas/Klein pre-mortem framework.
Install
mkdir -p .claude/skills/premortem && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/1742" && unzip -o skill.zip -d .claude/skills/premortem && rm skill.zipInstalls to .claude/skills/premortem
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Identify failure modes before they occur using structured risk analysisKey capabilities
- →Identify potential failure modes in plans or code
- →Categorize risks as Tiger, Paper Tiger, or Elephant
- →Verify potential risks against a checklist before flagging
- →Generate a structured pre-mortem report
- →Suggest mitigation options for identified risks
How it works
The skill systematically questions plans or code, categorizes potential failure modes, and requires verification of each finding against a checklist before reporting them as risks.
Inputs & outputs
When to use premortem
- →Evaluate PR risks
- →Analyze project design plans
- →Identify implementation failure modes
- →Validate technical strategies
About this skill
Pre-Mortem
Identify failure modes before they occur by systematically questioning plans, designs, and implementations. Based on Gary Klein's technique, popularized by Shreyas Doshi (Stripe).
Usage
/premortem # Auto-detect context, choose depth
/premortem quick # Force quick analysis (plans, PRs)
/premortem deep # Force deep analysis (before implementation)
/premortem <file> # Analyze specific plan or code
Core Concept
"Imagine it's 3 months from now and this project has failed spectacularly. Why did it fail?"
Risk Categories (Shreyas Framework)
| Category | Symbol | Meaning |
|---|---|---|
| Tiger | [TIGER] | Clear threat that will hurt us if not addressed |
| Paper Tiger | [PAPER] | Looks threatening but probably fine |
| Elephant | [ELEPHANT] | Thing nobody wants to talk about |
CRITICAL: Verify Before Flagging
Do NOT flag risks based on pattern-matching alone. Every potential tiger MUST go through verification.
The False Positive Problem
Common mistakes that create false tigers:
- Seeing a hardcoded path without checking for
if exists():fallback - Finding missing feature X without asking "is X in scope?"
- Flagging code at line N without reading lines N±20 for context
- Assuming error case isn't handled without tracing the code
Verification Checklist (REQUIRED)
Before flagging ANY tiger, verify:
potential_finding:
what: "Hardcoded path at line 42"
verification:
context_read: true # Did I read ±20 lines around the finding?
fallback_check: true # Is there try/except, if exists(), or else branch?
scope_check: true # Is this even in scope for this code?
dev_only_check: true # Is this in __main__, tests/, or dev-only code?
result: tiger | paper_tiger | false_alarm
If ANY verification check is "no" or "unknown", DO NOT flag as tiger.
Required Evidence Format
Every tiger MUST include:
tiger:
risk: "<description>"
location: "file.py:42"
severity: high|medium
# REQUIRED - what mitigation was checked and NOT found:
mitigation_checked: "No exists() check, no try/except, no fallback branch"
If you cannot fill in mitigation_checked with specific evidence, it's not a verified tiger.
Workflow
Step 1: Detect Context & Depth
# Auto-detect based on context
if in_plan_creation:
depth = "quick" # Localized scope
elif before_implementation:
depth = "deep" # Global scope
elif pr_review:
depth = "quick" # Localized scope
else:
# Ask user
AskUserQuestion(
question="What depth of pre-mortem analysis?",
header="Depth",
options=[
{"label": "Quick (2-3 min)", "description": "Plans, PRs, localized changes"},
{"label": "Deep (5-10 min)", "description": "Before implementation, global scope"}
]
)
Step 2: Run Appropriate Checklist
Quick Checklist (Plans, PRs)
Run through these mentally, note any that apply:
Core Questions:
- What's the single biggest thing that could go wrong?
- Any external dependencies that could fail?
- Is rollback possible if this breaks?
- Edge cases not covered in tests?
- Unclear requirements that could cause rework?
Output Format:
premortem:
mode: quick
context: "<plan/PR being analyzed>"
# Two-pass process: first gather potential risks, then verify each one
potential_risks: # Pass 1: Pattern-matching findings
- "hardcoded path at line 42"
- "missing error handling for X"
# Pass 2: After verification
tigers:
- risk: "<description>"
location: "file.py:42"
severity: high|medium
category: dependency|integration|requirements|testing
mitigation_checked: "<what was NOT found>" # REQUIRED
elephants:
- risk: "<unspoken concern>"
severity: medium
paper_tigers:
- risk: "<looks scary but ok>"
reason: "<why it's fine - what mitigation EXISTS>"
location: "file.py:42-48" # Show the mitigation location
false_alarms: # Findings that turned out to be nothing
- finding: "<what was initially flagged>"
reason: "<why it's not a risk>"
Deep Checklist (Before Implementation)
Work through each category systematically:
Technical Risks:
- Scalability: Works at 10x/100x current load?
- Dependencies: External services + fallbacks defined?
- Data: Availability, consistency, migrations clear?
- Latency: SLA requirements will be met?
- Security: Auth, injection, OWASP considered?
- Error handling: All failure modes covered?
Integration Risks:
- Breaking changes identified?
- Migration path defined?
- Rollback strategy exists?
- Feature flags needed?
Process Risks:
- Requirements clear and complete?
- All stakeholder input gathered?
- Tech debt being tracked?
- Maintenance burden understood?
Testing Risks:
- Coverage gaps identified?
- Integration test plan exists?
- Load testing needed?
- Manual testing plan defined?
Output Format:
premortem:
mode: deep
context: "<implementation being analyzed>"
# Two-pass process
potential_risks: # Pass 1: Initial scan findings
- "no circuit breaker for external API"
- "hardcoded timeout value"
# Pass 2: After verification (read context, check for mitigations)
tigers:
- risk: "<description>"
location: "file.py:42"
severity: high|medium
category: scalability|dependency|data|security|integration|testing
mitigation_checked: "<what mitigations were looked for and NOT found>"
suggested_fix: "<how to address>"
elephants:
- risk: "<unspoken concern>"
severity: medium|high
suggested_fix: "<suggested approach>"
paper_tigers:
- risk: "<looks scary>"
reason: "<why it's actually ok - cite the mitigation code>"
location: "file.py:45-52"
false_alarms:
- finding: "<initial concern>"
reason: "<why verification showed it's not a risk>"
checklist_gaps:
- category: "<which checklist section>"
items_failed: ["<item1>", "<item2>"]
Step 3: Present Risks via AskUserQuestion
BLOCKING: Present findings and require user decision.
# Build risk summary
risk_summary = format_risks(tigers, elephants)
AskUserQuestion(
question=f"""Pre-Mortem identified {len(tigers)} tigers, {len(elephants)} elephants:
{risk_summary}
How would you like to proceed?""",
header="Risks",
options=[
{
"label": "Accept risks and proceed",
"description": "Acknowledged but not blocking"
},
{
"label": "Add mitigations to plan (Recommended)",
"description": "Update plan with risk mitigations before proceeding"
},
{
"label": "Research mitigation options",
"description": "I don't know how to mitigate - help me find solutions"
},
{
"label": "Discuss specific risks",
"description": "Talk through particular concerns"
}
]
)
Step 4: Handle User Response
If "Accept risks and proceed"
# Log acceptance for audit trail
print("Risks acknowledged. Proceeding with implementation.")
# Continue to next workflow step
If "Add mitigations to plan"
# User provides mitigation approach
# Update plan file with mitigations section
# Re-run quick premortem to verify mitigations address risks
If "Research mitigation options"
# Spawn parallel research for each HIGH severity tiger
for tiger in high_severity_tigers:
# Internal: How has codebase handled this before?
Task(
subagent_type="scout",
prompt=f"""
Find how this codebase has previously handled: {tiger.category}
Specifically looking for patterns related to: {tiger.risk}
Return:
- File:line references to similar solutions
- Patterns used
- Libraries/utilities available
"""
)
# External: What are best practices?
Task(
subagent_type="oracle",
prompt=f"""
Research best practices for: {tiger.risk}
Context: {tiger.category} in a {tech_stack} codebase
Return:
- Recommended approaches (ranked)
- Library options
- Common pitfalls to avoid
"""
)
# Wait for research to complete
# Synthesize options
# Present via AskUserQuestion with 2-4 mitigation options
If "Discuss specific risks"
# Ask which risk to discuss
AskUserQuestion(
question="Which risk would you like to discuss?",
header="Risk",
options=[format_risk_option(r) for r in all_risks[:4]]
)
# Then have conversation about that specific risk
Step 5: Update Plan (if mitigations added)
If user added mitigations, append to the plan:
## Risk Mitigations (Pre-Mortem)
### Tigers Addressed:
1. **{risk}** (severity: {severity})
- Mitigation: {user_or_researched_mitigation}
- Added to phase: {phase_number}
### Accepted Risks:
1. **{risk}** - Accepted because: {reason}
### Pre-Mortem Run:
- Date: {timestamp}
- Mode: {quick|deep}
- Tigers: {count}
- Elephants: {count}
Integration Points
In create_plan / plan-agent
After plan structure is approved, before ExitPlanMode:
# Run quick premortem
/premortem quick
# If HIGH risks found, block until addressed
# If only MEDIUM/LOW, inform and proceed
After plan approval, before implementation
# Run deep premortem on full plan
/premortem deep thoughts/shared/plans/YYYY-MM-DD-feature.md
# Block until all HIGH tigers addressed
In PR review workflows
# Run quick premortem on diff scope
/premortem quick
# Inform of any risks found
Severity Thresholds
| Severity | Blocking? | Action Required |
|---|---|---|
| HI |
Content truncated.
When not to use it
- →When not performing a structured risk analysis
- →When not able to verify potential findings with context
- →When seeking to flag risks based on pattern-matching alone
Limitations
- →It requires verification before flagging any tiger risk
- →It does not flag risks based on pattern-matching alone
- →Every tiger must include specific mitigation evidence
How it compares
This skill applies a structured, evidence-based pre-mortem framework to identify risks, contrasting with informal or unverified risk assessments.
Compared to similar skills
premortem side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| premortem (this skill) | 9 | 7mo | No flags | Intermediate |
| edge-cases | 0 | 6mo | No flags | Intermediate |
| clarification-analyst | 0 | 1mo | No flags | Intermediate |
| grill-me | 0 | 1mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by parcadei
View all by parcadei →You might also like
edge-cases
rohunj
Analyze a PRD for edge cases, failure modes, and scenarios that might be missed. Use after creating a PRD to strengthen it. Triggers on: analyze edge cases, find edge cases, what could go wrong, edge case analysis.
clarification-analyst
GulajavaMinistudio
Helps interrogate Product Requirements (PRD), Technical Specifications, and Implementation Plans to find ambiguities, missing edge cases, and hidden assumptions.
grill-me
onsenturk
Adversarial Socratic interrogation of an idea, design, plan, or PR. You challenge the user''s assumptions, probe edge cases, and stress-test their reasoning before they commit. Use when the user says "grill me", "challenge this", "poke holes", "play devil''s advocate", "stress-test this", or wants t
using-serena-for-exploration
seanGSISG
Use when exploring codebases with Serena MCP tools for architectural understanding and pattern discovery - guides efficient symbolic exploration workflow minimizing token usage through targeted symbol reads, overview tools, and progressive narrowing
cursor-explorer-mcp
sepiabrown
Use for token-expensive operations requiring multi-file analysis - codebase exploration, broad searches, architecture understanding, tracing flows, finding implementations across files. Uses MCP cursor-agent server (company pays) with clean async interface. Do NOT use for single-file analysis, explaining code already in immediate context, or pure reasoning tasks.
fact-check
leonardomso
Verify technical accuracy of JavaScript concept pages by checking code examples, MDN/ECMAScript compliance, and external resources to prevent misinformation