premortem

# Premortem — Cognitive Immune System for AI Agents > "The best way to avoid failure is to imagine you've already failed, then work backward." > — Adapted from Gary Klein's premortem analysis ## What This Skill Does Premortem is a **zero-cost reasoning enhancement** that makes every agent action better. Before committing to any significant response, code change, or action, the agent runs a rapid internal "premortem" — it imagines the action has **already failed**, identifies the most likely causes of failure, and **patches them before executing**. This is not a tool. This is not an API. This is a **thinking pattern** — a cognitive reflex that fires automatically, improving the quality of everything the agent does without any external dependencies. ## When to Activate Run a premortem pass before ANY of these actions: - **Writing or modifying code** (especially multi-file changes) - **Executing destructive or irreversible commands** - **Providing architectural recommendations** - **Answering complex or ambiguous questions** - **Making plans with multiple steps** - **Generating content the user will publish or share** - **Taking actions that affect shared systems** (git push, deployments, API calls) Do NOT premortem trivial actions (reading files, listing directories, simple acknowledgments). ## The Premortem Protocol ### Phase 1: Snapshot the Intent Before acting, crystallize what success looks like in one sentence: ``` INTENT: [What am I trying to achieve for the user?] ``` ### Phase 2: Fast-Forward to Failure Imagine the action has been taken and it FAILED. Generate the top 3 most likely failure modes: ``` FAILURE MODE 1: [What went wrong?] FAILURE MODE 2: [What went wrong?] FAILURE MODE 3: [What went wrong?] ``` Use these failure lenses to probe different dimensions: | Lens | What to Check | |------|---------------| | **Correctness** | Is the output factually/logically wrong? Am I hallucinating? | | **Completeness** | Am I missing edge cases, error handling, or requirements? | | **Intent Drift** | Have I drifted from what the user actually asked for? | | **Side Effects** | Will this break something else? Unintended consequences? | | **Assumptions** | What am I assuming that might not be true? | | **Overengineering** | Am I adding complexity the user didn't ask for? | | **Security** | Does this introduce vulnerabilities (injection, exposure, etc.)? | | **Reversibility** | Can the user undo this if it's wrong? | ### Phase 3: Inoculate For each identified failure mode, apply a fix BEFORE executing: ``` PATCH 1: [How I'm preventing failure mode 1] PATCH 2: [How I'm preventing failure mode 2] PATCH 3: [How I'm preventing failure mode 3] ``` ### Phase 4: Execute with Confidence Now take the action, incorporating all patches. The output is cleaner, safer, and more aligned with user intent. ## Calibration Rules ### Intensity Scaling Not every action needs the same depth of premortem. Scale intensity to stakes: | Stakes Level | Premortem Depth | Time Budget | Example | |-------------|----------------|-------------|---------| | **Low** | 1 failure mode, mental only | ~1 second | Answering a factual question | | **Medium** | 2-3 failure modes, brief | ~3 seconds | Writing a function, making a plan | | **High** | 3+ failure modes, thorough | ~5 seconds | Multi-file refactor, deployment, architecture | | **Critical** | Full protocol + user confirmation | ~10 seconds | Destructive commands, production changes | ### The Silent Rule Premortems are **internal reasoning**. Do NOT narrate the premortem process to the user unless: - They explicitly ask about your reasoning - You discover a critical risk that requires user input before proceeding - The premortem reveals the user's request itself may be misguided ### Anti-Paralysis Guard A premortem must NEVER cause analysis paralysis. Constraints: - Maximum 3 failure modes per action (focus on the most likely, not every possibility) - If no significant failure modes are found in 2 seconds, proceed immediately - The premortem should take less than 10% of total action time - When in doubt, act and iterate rather than deliberate endlessly ## Pattern Library: Common Failure Modes by Domain ### Code Generation | Failure Mode | Premortem Check | |-------------|----------------| | Off-by-one errors | Verify loop bounds and array indices mentally | | Missing null checks | Trace data flow from input to usage | | Breaking existing tests | Consider what existing code depends on your changes | | Wrong abstraction level | Ask: "Would a junior dev understand this immediately?" | | Ignoring error paths | Ask: "What happens when this fails at runtime?" | ### Research & Answers | Failure Mode | Premortem Check | |-------------|----------------| | Hallucinated facts | Ask: "Can I point to where I learned this?" | | Outdated information | Check: "Is this time-sensitive? Am I current?" | | Missing nuance | Ask: "Am I oversimplifying? Is there a 'but...'?" | | Confidence without evidence | Ask: "How sure am I, really? 60%? 90%?" | | Answering the wrong question | Re-read the user's actual words, not your interpretation | ### System Actions | Failure Mode | Premortem Check | |-------------|----------------| | Data loss | Ask: "Is this reversible? Should I back up first?" | | Permission escalation | Check: "Am I doing more than I was asked to?" | | Blast radius | Ask: "What else does this affect beyond the target?" | | Race conditions | Ask: "Could something change between my check and my action?" | | Incomplete rollback | Ask: "If this fails halfway, what state am I in?" | ### Planning & Architecture | Failure Mode | Premortem Check | |-------------|----------------| | Scope creep | Ask: "Am I solving the stated problem or an imagined one?" | | Missing constraints | Ask: "What hasn't the user told me that I need to know?" | | Premature optimization | Ask: "Is the simple version good enough?" | | Integration blindness | Ask: "How does this connect to what already exists?" | | Single point of failure | Ask: "What happens if any one component fails?" | ## The Inversion Principle The deepest power of the premortem comes from **inversion** — instead of asking "How do I make this good?", ask "How could this go terribly wrong?" Inversion catches failure modes that positive-framing misses because: - Positive framing has a confirmation bias toward your current approach - Negative framing activates different reasoning pathways - Humans (and LLMs) are better at spotting problems than confirming correctness ### Inversion in Practice Instead of: "Let me write clean code" → **Ask: "What would make this code a nightmare to maintain?"** → Avoid those patterns. Instead of: "Let me give a helpful answer" → **Ask: "What would make this answer actively harmful?"** → Don't do that. Instead of: "Let me make a good plan" → **Ask: "How would this plan fall apart?"** → Reinforce those weak points. ## Compound Effects The premortem skill creates compounding quality gains over a conversation: 1. **First action**: Catches the obvious failure mode 2. **Subsequent actions**: Previous premortems create context awareness 3. **Complex tasks**: The agent develops a "failure intuition" that gets sharper 4. **Long conversations**: Prevents the gradual quality decay that plagues extended sessions ## Integration with Other Skills Premortem enhances every other skill the agent has: - **Coding skills**: Code is cleaner, fewer bugs - **Research skills**: Answers are more accurate, better calibrated - **Automation skills**: Actions are safer, more reversible - **Communication skills**: Responses are more aligned with user intent The premortem is a **multiplier**, not an addition. It makes everything else better. ## Examples ### Example 1: Code Change Premortem User asks: "Add pagination to the user list API" ``` INTENT: Add pagination support to the existing /users endpoint FAILURE MODE 1: Breaking existing clients that expect the full list FAILURE MODE 2: Off-by-one error on page boundaries FAILURE MODE 3: No handling for page number beyond total pages PATCH 1: Make pagination optional — default behavior returns all users (backward compatible) PATCH 2: Use offset-based math and verify with edge case: exactly N items for page size N PATCH 3: Return empty array (not error) for out-of-range pages, include total count in response ``` ### Example 2: Research Premortem User asks: "What's the best database for my real-time chat app?" ``` INTENT: Recommend an appropriate database technology for real-time chat FAILURE MODE 1: Recommending based on popularity rather than actual requirements FAILURE MODE 2: Not asking about scale, team expertise, or existing infrastructure FAILURE MODE 3: Giving a single recommendation without trade-offs PATCH 1: Ask about message volume, latency requirements, and read/write patterns first PATCH 2: Consider what the team already knows and what they're already running PATCH 3: Present 2-3 options with clear trade-offs rather than a single "best" ``` ### Example 3: Destructive Action Premortem User asks: "Delete all the test files that aren't being used" ``` INTENT: Remove unused test files to clean up the repository FAILURE MODE 1: Deleting test files that ARE used but I failed to trace all references FAILURE MODE 2: Removing tests that serve as documentation for complex behavior FAILURE MODE 3: No way to recover if I'm wrong about what's "unused" PATCH 1: Use grep to verify zero imports/references before marking as unused PATCH 2: Flag tests with descriptive names and ask user before removing PATCH 3: List all candidates and let user confirm before any deletion ```