Pre-Mortem Planner

The Problem

Your AI agent produces a confident plan. It outlines the steps, assigns the resources, and sets the timeline.

It did not ask: what if this fails?

Pre-mortem analysis — imagining that the plan has already failed and working backwards to identify why — is one of the most effective techniques for surfacing risks that optimistic planning misses. It is also the technique that AI agents almost never apply unless specifically told to.

The result: plans that look complete but have no account for their own failure modes. When something goes wrong, the failure was predictable. It just wasn't predicted.

How It Works

Before generating any plan, recommendation, or significant output, this skill requires the agent to complete two steps:

Step 1 — Five failure scenarios
The agent enumerates five specific ways the current task could fail. At least one must be unique to this specific task — not a generic risk that applies to every task.

Step 2 — Pre-mortem declaration
The agent identifies which failure scenario is most likely given the current context, and states its mitigation before proceeding to the actual output.

Only after both steps are complete does the agent generate the plan.

Step 1: Five Failure Scenarios

Each failure scenario must be specific to the task at hand. Generic placeholders are not valid.

Format:

Failure scenarios:
F1: [Fixed] Information not verified — agent proceeds from memory or assumption without checking
F2: [Task-specific] [concrete description of how this specific task could fail]
F3: [Task-specific] [concrete description of how this specific task could fail]
F4: [Task-specific] [concrete description of how this specific task could fail]
F5: [Task-specific] [concrete description of how this specific task could fail]

F1 is always fixed — unverified information is the most common and universal failure mode. It does not count toward the task-specific requirement.

F2–F5 must be task-specific. A failure scenario is task-specific if it could only be written after reading the current task description. If it could apply unchanged to a completely different task, it is generic and must be rewritten.

Invalid examples (too generic):

• "The output might be incorrect"
• "There could be misunderstandings"
• "The user might not be satisfied"

Valid examples (task-specific):

• "The API endpoint assumed to be stable has changed since the last documentation update"
• "The persona described in the brief conflicts with the tone requirements elsewhere in the document"
• "The timeline assumes a dependency that has not been confirmed as available"

Step 2: Pre-Mortem Declaration

After listing five failure scenarios, the agent selects the one most likely to occur given the current context and states its mitigation.

Format:

Pre-mortem: The most likely failure is [F-number] — [restatement of the scenario].
Mitigation: [specific action taken or constraint applied to reduce this risk]

The mitigation must be actionable — not "be careful about this" but a specific adjustment to how the output will be generated.

Before / After

Before:

Agent: "Here's the project plan: Phase 1 — research (2 days). Phase 2 — draft (3 days). Phase 3 — review (1 day). Total: 6 days."

After (with Pre-Mortem Planner):

Failure scenarios:
F1: [Fixed] Information used in planning is outdated
F2: Phase 2 draft time assumes access to all stakeholders for clarification — availability not confirmed
F3: "Review" in Phase 3 is undefined — no clarity on who reviews or what the acceptance criteria are
F4: The 6-day timeline assumes no dependencies on external deliverables — none listed in the brief
F5: Scope of "research" in Phase 1 is ambiguous — could expand significantly if primary sources are unavailable

Pre-mortem: Most likely failure is F3 — undefined review criteria means Phase 3 has no completion condition.
Mitigation: Flag the undefined review criteria in the plan output and request clarification before Phase 3 begins.

Plan: [generated with F3 flagged explicitly]

Hard Rules

1. Five failure scenarios before any plan. The scenarios are generated before the output — not as an afterthought appended to a completed plan.
2. F1 is always fixed. Unverified information is always failure scenario one. It does not need to be invented each time.
3. F2–F5 must be task-specific. A scenario that could apply unchanged to a different task is generic and must be rewritten before proceeding.
4. The pre-mortem declaration is mandatory. After listing five scenarios, the agent must identify the most likely one and state a specific mitigation. "All risks are equal" is not a valid pre-mortem.
5. The mitigation must be actionable. "Be careful" is not a mitigation. The mitigation is a specific constraint or adjustment applied to the output being generated.
6. The plan is generated after both steps are complete. Generating the plan and adding failure scenarios afterwards is not pre-mortem analysis — it is decoration.