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:

CODEBLOCK0

Phase 2: Fast-Forward to Failure

Imagine the action has been taken and it FAILED. Generate the top 3 most likely failure modes:

CODEBLOCK1

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:

CODEBLOCK2

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. 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"

CODEBLOCK3

Example 2: Research Premortem

User asks: "What's the best database for my real-time chat app?"

CODEBLOCK4

Example 3: Destructive Action Premortem

User asks: "Delete all the test files that aren't being used"

CODEBLOCK5