Skip to content
Development
Skill

/premortem

Identify failure modes before they occur using structured risk analysis

From plugin
continuous-claude-v3
3.9k156 skills32 agents

Claude Code

$ npx -y skills add parcadei/Continuous-Claude-v3 --skill premortem --agent claude-code

SKILL.md

premortem.SKILL.md
name: premortem
description: Identify failure modes before they occur using structured risk analysis
allowed-tools: [Read, Grep, Glob, Task, AskUserQuestion, TodoWrite]

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:** 1. What's the single biggest thing that could go wrong? 2. Any external dependencies that could fail? 3. Is rollback possible if this breaks? 4. Edge cases not covered in tests? 5. 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 appr
Read more
@parcadei
Ships withcontinuous-claude-v3

A persistent, learning, multi-agent development environment built on Claude Code Continuous Claude transforms Claude Code into a continuously learning system that maintains context across sessions, orchestrates specialized agents, and eliminates wasting

3.9k156 skills32 agents
Get the whole plugin

Stars on GitHub

Momentum

stars in total
3.9k
Star history of parcadei/Continuous-Claude-v3 on GitHub, a chart by star-history.com

Other skills on continuous-claude-v3.

More skills from other plugins.

brainstorming
Auto-invoked

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…

@obra@obraInstall Skill
ask-matt

ask-matt

Ask which skill or flow fits your situation. A router over the skills in this repo.

skills2w309k
@mattpocock@mattpocockInstall Skill
accessibility
Auto-invoked

accessibility

Design, implement, and audit accessible UI to WCAG 2.2 Level AA across Web, iOS, and Android — semantic ARIA roles and labels,…

ecc2w293k
@affaan-m@affaan-mInstall Skill
compiler-commit

compiler-commit

Use when you want to verify compiler changes and commit with the correct convention. Runs tests, lint, and format, then commits…

react5d252k
@facebook@facebookInstall Skill

Questions about premortem.

Which coding agents can use premortem?
premortem installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.