=========== 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: .. code-block:: text /wf:pre-mortem Default Judges -------------- The pre-mortem uses 4 complementary failure-specialist judges: .. list-table:: :header-rows: 1 :widths: 5 25 70 * - # - 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. .. code-block:: bash # 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. .. list-table:: :header-rows: 1 :widths: 20 10 15 55 * - 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):** .. code-block:: yaml --- # No frontmatter needed — defaults are designed for pre-mortem --- **Override rounds only:** .. code-block:: yaml --- rounds: 3 --- **Full override (rare):** .. code-block:: yaml --- 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 :doc:`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: .. code-block:: markdown | # | 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 ----------------- .. code-block:: markdown # 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:** .. code-block:: text > /wf:pre-mortem using docs/plans/deploy-payment-v2.md **Pre-mortem from default location:** .. code-block:: text > # Create the platform default input file with your plan > /wf:pre-mortem **Pre-mortem on a plan with code context:** .. code-block:: text > /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 ------------------------------------------- .. list-table:: :header-rows: 1 :widths: 20 30 25 25 * - 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