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 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: If ANY verification check is "no" or "unknown", DO NOT flag as tiger. Required Evidence Format Every tiger MUST include: If you cannot fill in mitigation checked with specific evidence, it's not a verified tiger. Workflow Step 1: Detect Context & Depth 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: 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: Step 3: Present Risks via AskUserQuestion BLOCKING: Present findings and require user decision. Step 4: Handle User Response If "Accept risks and proceed" If "Add mitigations to plan" If "Research mitigation options" If "Discuss specific risks" Step 5: Update Plan (if mitigations added) If user added mitigations, append to the plan: Integration Points In create plan / plan agent After plan structure is approved, before ExitPlanMode: After plan approval, before implementation In PR review workflows Severity Thresholds Severity Blocking? Action Required HIGH Yes Must address or explicitly accept MEDIUM No Inform user, recommend addressing LOW No Note for awareness Example Session References [Pre Mortems by Shreyas Doshi](https://coda.io/@shreyas/pre mortems) [Gary Klein's Original Research](https://hbr.org/2007/09/performing a project premortem) [Project Pre Mortem Guide Mountain Goat Software](https://www.mountaingoatsoftware.com/blog/use a pre mortem to identify project risks before they occur)