Pre-Mortem

Pre-Mortem#

Run an adversarial pre-mortem failure analysis with platform-neutral multi-persona orchestration, producing a risk register with severity ratings and consolidated mitigations.

Note

Generated artifacts use the platform orchestration adapter. Claude can use agent teams where available; Codex and OpenCode ask before subagents and otherwise use the sequential persona fallback.

Description#

The pre-mortem skill runs 4 failure-specialist personas who independently assume the plan has already been implemented and has FAILED. Each persona works backward from their specialist perspective to explain why it failed, producing failure modes with severity and likelihood ratings.

This is based on the pre-mortem technique from project management: by assuming failure upfront, analysts overcome optimism bias and surface risks that “what could go wrong?” brainstorming often misses.

Relationship to council:

Pre-mortem follows the council workflow pattern with hard-coded failure specialists and more conservative verdict logic. It is a standalone skill, not a wrapper around council.

Relationship to debate:

  • Debate uses HydraMCP for multi-model review

  • Pre-mortem uses platform-native persona orchestration for multi-agent failure analysis

You can chain them: pre-mortem first for failure analysis, then debate to cross-validate mitigations with another model family.

Triggers#

The skill activates when you mention:

  • Running a pre-mortem

  • Failure analysis

  • Risk analysis

  • What could go wrong with a plan

  • Stress testing a plan

Explicit invocation:

/wf:pre-mortem

Default Judges#

The pre-mortem uses 4 complementary failure-specialist judges:

#

Name

Perspective

1

Integration Failure Analyst

Interface mismatches, dependency failures, migration gaps, system boundary assumptions

2

Operations Failure Analyst

Deployment, monitoring, scaling, single points of failure, capacity limits, recovery gaps

3

Data Failure Analyst

Data integrity, race conditions, schema migration, backup gaps, corruption vectors

4

Devil’s Advocate

Challenges fundamental assumptions, unstated dependencies, optimistic timelines, scope creep

These judges can be overridden via frontmatter, but the defaults are designed to cover complementary failure domains and overriding is not recommended.

Input Format#

The pre-mortem takes a markdown file with optional YAML frontmatter.

# Create a pre-mortem input file
vi .claude/pre-mortem.md  # or .codex/pre-mortem.md / .opencode/pre-mortem.md

Search order:

  1. Explicit path provided by the user

  2. the platform default input file in the current repository root

  3. If not found, shows a minimal example for the user to create

Frontmatter Fields#

All fields are optional. Pre-mortem applies conservative defaults.

Field

Type

Default

Description

judges

list

4 failure specialists

Override default analysts (not recommended)

rounds

int

2

Number of inter-judge debate rounds

verdict_threshold

int

4 (unanimous)

Judges that must agree for PASS

output_dir

string

"resources/agent-docs/reviews/pre-mortems"

Where transcripts are written

context_budget_kb

int

100

Max total KB for embedded @file context

Key differences from council defaults:

  • 4 judges (vs council’s 3)

  • Unanimous threshold (vs council’s majority) — deliberately conservative

  • Separate output directory — resources/agent-docs/reviews/pre-mortems/

  • Mode is always validate — not configurable

Example Frontmatter#

Minimal (recommended — use all defaults):

---
# No frontmatter needed — defaults are designed for pre-mortem
---

Override rounds only:

---
rounds: 3
---

Full override (rare):

---
rounds: 2
verdict_threshold: 3
output_dir: resources/agent-docs/reviews/pre-mortems
---

@file Auto-Detection#

Same mechanism as the council and debate skills. The pre-mortem scans the markdown body for @path/to/file references and embeds their contents into judge prompts.

See the Council documentation for full details on detection rules and embedding logic.

Critical Framing#

Each persona receives modified instructions that force the pre-mortem perspective:

“CRITICAL FRAMING: Assume this plan has already been implemented and has FAILED. Your job is to work backward and explain WHY it failed from your specialist perspective.”

Each persona produces:

  • 3-5 failure modes with:

    • Severity: HIGH / MEDIUM / LOW

    • Likelihood: HIGH / MEDIUM / LOW

    • Mitigation: Specific preventive action

  • Verdict: PASS / WARN / FAIL

    • PASS: No unmitigated HIGH-severity risks

    • WARN: HIGH risks exist but all have proposed mitigations

    • FAIL: One or more unmitigable HIGH-severity risks

Workflow#

  1. Find and parse input file

    • Locate the markdown file using the search order

    • Split YAML frontmatter from markdown body

    • Apply pre-mortem defaults (mode=validate, threshold=unanimous)

  2. Detect and embed context files

    • Scan body for @file references outside code fences

    • Read and embed files within budget

  3. Configure judges

    • Use 4 default failure specialists (unless overridden)

  4. Create agent team

    • Start a session-scoped persona execution run

    • Lead coordinates all communication and writes output files

  5. Spawn judges and seed context

    • Each persona receives the plan, embedded context, role instructions, and the critical pre-mortem framing

    • Each persona produces initial failure assessment

  6. Execute debate rounds

    • For each round, each judge receives all other judges’ latest responses

    • Judges look for failure interactions, missed failure modes, insufficient mitigations

  7. Consolidate verdicts and build risk register

    • Apply conservative verdict logic

    • Build risk register table from all failure modes

    • Produce consolidated recommendations

  8. Clean up agent team

    • Cleanup runs unconditionally, even on error

  9. Write transcript

    • Write to output_dir/pre-mortem-YYYY-MM-DD-HHMMSS.md

Verdict Logic#

Pre-mortem uses more conservative verdict logic than council:

  • FAIL if ANY judge identifies an unmitigated HIGH-severity risk

  • WARN if HIGH-severity risks exist but all have proposed mitigations

  • PASS only if ALL judges agree no unmitigated HIGH-severity risks

This means a single unmitigated HIGH risk from any analyst produces an overall FAIL verdict.

Risk Register#

The transcript includes a consolidated risk register table:

| # | Failure Mode | Analyst | Severity | Likelihood | Mitigation | Status |
|---|-------------|---------|----------|------------|------------|--------|
| 1 | DB migration exceeds window | Operations | HIGH | HIGH | Add parallel run | MITIGATED |
| 2 | No rollback path | Integration | HIGH | MEDIUM | None | UNMITIGATED |

Status values:

  • MITIGATED — a specific mitigation has been proposed

  • ACCEPTED — risk acknowledged, no mitigation needed (LOW severity)

  • UNMITIGATED — no adequate mitigation identified (triggers FAIL if HIGH)

Consolidated Recommendations#

The transcript organises recommendations by urgency:

  • Immediate Actions — from HIGH-severity risks; must be addressed before proceeding with the plan

  • Recommended Mitigations — from MEDIUM-severity risks; should be planned

  • Accepted Risks — LOW-severity risks; documented but no action required

Transcript Format#

# Pre-Mortem Report

**Topic:** Deploy Payment Service v2
**Document:** platform default input file
**Date:** 2026-02-18 17:00:00
**Rounds:** 2
**Verdict Threshold:** 4 of 4 (unanimous)

## Analysts

| # | Name | Perspective | Final Verdict |
|---|------|-------------|---------------|
| 1 | Integration Failure Analyst | Interfaces, dependencies | WARN |
| 2 | Operations Failure Analyst | Deployment, monitoring | FAIL |
| 3 | Data Failure Analyst | Data integrity, corruption | WARN |
| 4 | Devil's Advocate | Assumptions, timelines | FAIL |

## Overall Verdict: FAIL

[summary referencing unmitigated HIGH risks]

## Risk Register

[consolidated table]

## Round 1
...

## Consolidated Recommendations

### Immediate Actions
### Recommended Mitigations
### Accepted Risks

## Verdict Summary

| Analysts PASS | Analysts WARN | Analysts FAIL | Threshold | Overall |
|---------------|---------------|---------------|-----------|---------|
| 0             | 2             | 2             | 4 of 4    | FAIL    |

Example Usage#

Pre-mortem on a deployment plan:

> /wf:pre-mortem using docs/plans/deploy-payment-v2.md

Pre-mortem from default location:

> # Create the platform default input file with your plan
> /wf:pre-mortem

Pre-mortem on a plan with code context:

> /wf:pre-mortem using migration-plan.md

Where migration-plan.md references source files with @src/db/migrate.py.

Error Handling#

  • Plan file not found: Shows minimal example for the user to create

  • Platform-native persona orchestration unavailable: Use the generated sequential fallback and record the downgrade

  • Analyst fails to respond: Error recorded in transcript, remaining analysts continue

  • ``@file`` not found: Warning in transcript, file skipped

  • ``smart_read`` fails: File skipped, warning logged

  • Frontmatter parse error: Reports the YAML error and line number

  • Team cleanup fails: Warning logged, does not block output

Limits#

  • Judges: 4 default failure specialists. Override is possible but not recommended.

  • Rounds: 2 recommended. Failure analysis benefits from cross-pollination but rarely needs more.

  • Token cost: 4 judges x (1 initial + 2 rounds) = 12 agent turns plus coordination overhead. More expensive than council. Reserve for plans where failure cost is high.

  • Verdict threshold: Unanimous by default. This is deliberately conservative.

  • Context budget: Default 100 KB. Set to 0 to disable file embedding.

  • Non-deterministic: Real output varies between runs.

  • One team per session: Do not run pre-mortem while another team is active.

When to Use Pre-Mortem vs Council vs Debate#

Skill

Best For

Technology

Cost

Pre-mortem

Failure analysis of risky plans

Platform-native persona orchestration (Claude only)

~12 agent turns

Council

General validation from multiple angles

Platform-native persona orchestration (Claude only)

~6 agent turns

Debate

Cross-model review and synthesis

HydraMCP (any model)

~6 ask_model calls

Suggested chain for high-stakes decisions:

  1. Pre-mortem — identify what could go wrong

  2. Address findings — update the plan based on pre-mortem output

  3. Council — validate the revised plan

  4. Debate — cross-validate with a different model family

Contents