# Pre Mortem

> Guide prospective hindsight analysis to identify project risks before failure occurs. Teams imagine the project has failed spectacularly, then work backward to identify causes. Increases risk identification by 30% compared to traditional planning. Use when you say "run a pre-mortem on", "what could cause this to fail", "identify project risks", or "what could go wrong with". Do NOT use to stress-test a single decision's reasoning (use decision-critic).

- Skill: `rjmurillo/pre-mortem` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add rjmurillo/pre-mortem`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rjmurillo/pre-mortem/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: rjmurillo (https://skillmd.com/u/rjmurillo)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/rjmurillo/pre-mortem

---


# Pre-Mortem Risk Identification

When this skill activates, you become a pre-mortem facilitator. Your role is to guide users through prospective hindsight analysis, helping them identify project risks by imagining failure has already occurred.

## Triggers

Activate when the user:

- `Run a pre-mortem on...`
- `What could cause this project to fail?`
- `Identify project risks for...`
- `What could go wrong with...`
- `Pre-mortem analysis`

## Quick Reference

| Phase | Duration | Output |
|-------|----------|--------|
| 1. Brief | 2-3 min | Project context documented |
| 2. Failure Announcement | 30 sec | Mindset shift established |
| 3. Independent Analysis | 3-5 min | Individual failure reasons |
| 4. Round-Robin Collection | 5-10 min | Consolidated failure list |
| 5. Review and Mitigate | 10-15 min | Risk inventory with mitigations |

## When to Use

Use this skill when:

- Starting a new project or feature and want to identify risks upfront
- Team is overly optimistic and potential downsides need surfacing
- Stakeholders need to understand risk before committing resources
- After major scope changes to reassess risk landscape

Use [threat-modeling](../threat-modeling/SKILL.md) instead when:

- Analyzing security threats specifically (STRIDE, attack trees)
- Need structured vulnerability assessment, not general project risk

Use [decision-critic](../decision-critic/SKILL.md) instead when:

- Challenging a specific decision, not brainstorming broad risks

## Why Pre-Mortem Works

Research by Gary Klein demonstrates that **prospective hindsight** (imagining an event has already occurred) increases the ability to identify reasons for outcomes by 30%.

**Key psychological benefits:**

1. **Reduces "damn-the-torpedoes" attitude** - Acknowledging failure is possible
2. **Creates psychological safety** - Dissenters can voice concerns as analysis, not criticism
3. **Surfaces hidden knowledge** - People share what they know but fear saying
4. **Catches blind spots early** - Before commitment and sunk costs

## Process

### Phase 1: Project Brief (2-3 minutes)

**Input Required:**

- Project name and objective
- Timeline and key milestones
- Team composition (if team context)
- Success criteria

**Actions:**

1. Document the project scope clearly
2. Identify key stakeholders
3. Note any constraints or dependencies
4. Confirm understanding with user

**Output:** Project context document

### Phase 2: Failure Announcement (30 seconds)

**The critical mindset shift.**

Announce to the user (or team):

> "The project has failed. It is [timeline endpoint]. The project did not just miss its goals, it failed spectacularly. Your task now is to identify all the reasons why it failed."

**Important:** Use past tense. The failure has already happened. This is not speculation about what "might" happen; it "did" happen.

### Phase 3: Independent Analysis (3-5 minutes)

**For individual context:**

- User writes down 5-10 reasons why the project failed
- No filtering or evaluation yet
- Include both obvious and "unlikely" causes
- Consider technical, human, organizational, and external factors

**For team context:**

- Each person writes independently
- No discussion or sharing yet
- Silent reflection maximizes diversity of thought

**Prompt the user:**
> "Write down every reason you can think of for why this project failed. Include causes you consider unlikely. Do not filter yourself. You have 3-5 minutes."

**Output:** Raw list of failure reasons

### Phase 4: Round-Robin Collection (5-10 minutes)

**For individual context:**

- Review each failure reason
- Group by category (see Categories below)
- No evaluation yet, just collection

**For team context:**

- Go around the room, each person shares ONE reason
- Continue rounds until all reasons exhausted
- Record without discussion or debate
- No "that won't happen" or "we already thought of that"

**Categories for grouping:**

1. **Technical** - Technology, architecture, implementation
2. **People** - Skills, availability, communication
3. **Process** - Methodology, workflow, coordination
4. **Organizational** - Politics, priorities, resources
5. **External** - Market, competitors, regulations, dependencies
6. **Unknown Unknowns** - Black swan events, assumptions

**Output:** Categorized failure reasons

### Phase 5: Review and Mitigate (10-15 minutes)

**For each failure reason:**

1. **Assess likelihood** (1-5 scale)
   - 1: Very unlikely
   - 2: Unlikely
   - 3: Possible
   - 4: Likely
   - 5: Very likely

2. **Assess impact** (1-5 scale)
   - 1: Minor inconvenience
   - 2: Delays
   - 3: Significant setback
   - 4: Major failure
   - 5: Project-killing

3. **Calculate risk score**: Likelihood x Impact

4. **Identify mitigation strategies:**
   - Prevention: How to stop it from happening
   - Detection: How to know early if it is happening
   - Response: What to do if it happens

5. **Assign ownership** (if team context)

**Prioritization:**

- Risk score 15-25: Critical, address immediately
- Risk score 8-14: High, plan mitigation
- Risk score 4-7: Medium, monitor
- Risk score 1-3: Low, accept or defer

**Output:** Complete risk inventory (see template)

## Output Template

Generate the risk inventory using this structure:

```markdown
# Pre-Mortem Risk Inventory

**Project:** [Name]
**Date:** [Date]
**Participants:** [Names or "Individual Analysis"]

## Project Context

- **Objective:** [What success looks like]
- **Timeline:** [Start to end]
- **Key Dependencies:** [Critical external factors]

## Risk Summary

| Priority | Count | Top Risk |
|----------|-------|----------|
| Critical | N | [Highest scoring risk] |
| High | N | [Second highest category risk] |
| Medium | N | |
| Low | N | |

## Critical Risks (Score 15-25)

### R1: [Risk Name]

- **Category:** [Technical/People/Process/Organizational/External]
- **Failure Scenario:** [How this causes project failure]
- **Likelihood:** [1-5] | **Impact:** [1-5] | **Score:** [L x I]
- **Root Cause:** [Why this might happen]
- **Mitigation:**
  - Prevention: [How to avoid]
  - Detection: [Early warning signs]
  - Response: [Contingency plan]
- **Owner:** [Person responsible]
- **Status:** [Open/Mitigating/Accepted]

[Repeat for each critical risk]

## High Risks (Score 8-14)

[Same structure as Critical]

## Medium Risks (Score 4-7)

[Abbreviated: Name, Category, Score, One-line mitigation]

## Low Risks (Score 1-3)

[List only: Name and score]

## Action Items

| Action | Owner | Due Date | Risk Addressed |
|--------|-------|----------|----------------|
| [Specific action] | [Name] | [Date] | R1, R3 |

## Review Schedule

- **Next review:** [Date]
- **Review frequency:** [Weekly/Bi-weekly/Monthly]
```

## Scripts

### pre-mortem.py

Validates risk inventory completeness and calculates aggregate statistics.

```bash
python3 .claude/skills/pre-mortem/scripts/pre-mortem.py \
  --inventory-path "$INVENTORY_PATH" \
  --validate
```

**Exit Codes:**

- 0: Valid inventory with all required fields
- 1: Invalid arguments
- 10: Validation failed (missing required sections)

## Anti-Patterns

| Avoid | Why | Instead |
|-------|-----|---------|
| Skipping Phase 2 | Mindset shift is critical for effectiveness | Always announce failure explicitly |
| Allowing discussion during Phase 3 | Reduces diversity of thought | Enforce silent writing |
| Filtering "unlikely" causes | Miss black swan events | Include all causes, prioritize later |
| Stopping at identification | Risk without mitigation is incomplete | Always complete Phase 5 |
| One-time exercise | Projects evolve, new risks emerge | Schedule periodic reviews |

## Verification

After completing a pre-mortem, run the bundled validator and require exit 0:

```bash
python3 .claude/skills/pre-mortem/scripts/pre-mortem.py \
  --inventory-path "$INVENTORY_PATH" \
  --validate
echo "exit=$?"   # must be 0; exit 10 means missing required sections (inventory is not valid)
```

- [ ] `pre-mortem.py` exited 0 (exit 10 = validation failed; exit 1 = invalid arguments; non-zero = blocked)
- [ ] All 5 phases completed (Brief, Failure Announcement, Analysis, Collection, Mitigation)
- [ ] Risk inventory generated with risk scores (Likelihood x Impact)
- [ ] All Critical/High risks have mitigation strategies, each with the full Prevention/Detection/Response triad (a prevention-only mitigation FAILS the gate and MUST be completed)
- [ ] Each mitigation has Prevention, Detection, and Response
- [ ] Action items assigned with owners and due dates
- [ ] Review schedule established

> **Gate rule:** `pre-mortem.py` exit 0 is necessary but not sufficient. The script flags `has_mitigation` true on a single `**Prevention:**` line, so a Critical/High risk can exit 0 with an incomplete mitigation. Until the script is tightened, manual verification MUST confirm every Critical/High mitigation carries Prevention, Detection, and Response. A prevention-only Critical/High mitigation does not pass; complete the triad before the pre-mortem is done.

## Facilitation Tips

**For team settings:**

- Emphasize no blame or criticism
- Senior members speak last in round-robin
- Celebrate thorough risk identification
- Treat skeptics as valuable, not negative

**For individual use:**

- Role-play multiple perspectives (developer, user, manager)
- Challenge your own assumptions explicitly
- Consider "what would my critics say?"

## Extension Points

1. **Custom Categories:** Add domain-specific risk categories
2. **Risk Templates:** Pre-built risks for common project types
3. **Integration:** Link to issue trackers for action item follow-up
4. **Quantification:** Add financial impact estimation

## Related Skills

| Skill | Relationship |
|-------|--------------|
| decision-critic | Post-decision validation (pre-mortem is pre-decision) |
| milestone-planner | Use pre-mortem output to inform planning |
| architect | Technical risks feed into ADR considerations |

## References

| Reference | Purpose |
|-----------|---------|
| `references/mental-models-galls-law.md` | Complexity-driven risk identification using Gall's Law |
| `references/strategy-ooda-loop.md` | Iterative risk review cadence using OODA Loop |

### Academic Sources

- Klein, G. (2007). "Performing a Project Premortem." Harvard Business Review.
- Mitchell, D. J., et al. (1989). "Back to the Future: Temporal Perspective in the Explanation of Events." Journal of Behavioral Decision Making.