/post-mortem

name: post-mortem
description: Run a structured post-mortem after a failure, missed target, or incident. Use when you need to learn from what went wrong without blame.

Post-Mortem & Retrospective

Turn a failure into actionable learning in 2-3 hours instead of a week of finger-pointing. Claude structures the timeline, surfaces contributing factors objectively, and drafts action items. You facilitate the conversation and ensure the team learns without blame.

When to Use

• A launch went poorly (missed targets, quality issues, user backlash)
• A major incident or outage occurred
• A quarter's OKRs were significantly missed
• A key initiative was killed after significant investment
• A process breakdown caused preventable problems

When NOT to Use

• Things went well and you want to celebrate — do that, but not with this skill
• You're doing routine sprint retrospectives — those are lighter weight than this
• The problem is ongoing — fix it first, post-mortem after

The AI-Native Approach

| Step | Time | Claude Does | You Do | |---|---|---|---| | Build the timeline | 30 min | Structure events chronologically from your input | Validate accuracy, fill gaps | | Identify contributing factors | 45 min | Categorize factors objectively without blame | Facilitate team input, add context | | Extract lessons | 30 min | Distill what was learned and what should change | Decide which lessons lead to action | | Draft action items | 30 min | Structure specific, assigned, time-bound actions | Confirm ownership and commitment | | Write the post-mortem doc | 15 min | Format the complete document | Review and distribute |

Process

Step 1: Build the Timeline (30 minutes)

We're running a post-mortem on [what happened].

Here's what I know about the sequence of events:
[Paste your notes — dates, decisions, milestones, when things went wrong]

Build a chronological timeline:
- Key decisions made and by whom (no blame — just facts)
- When warning signs appeared
- When the problem became visible
- Actions taken in response
- Final outcome

Flag: at which points could a different decision have changed the outcome?

Step 2: Identify Contributing Factors (45 minutes)

Based on the timeline, identify contributing factors. Categorize each:

1. Process factors: Were there process gaps that allowed this?
2. Communication factors: Was information available but not shared?
3. Technical factors: Were there system limitations or failures?
4. Scope/planning factors: Was the plan realistic given constraints?
5. External factors: Did something outside our control contribute?

For each factor:
- What happened (factual, blameless description)
- Why it mattered (how it contributed to the outcome)
- Whether it was visible at the time (could we have caught it?)
- Whether it's systemic (likely to recur) or one-off

Do NOT assign individual blame. Focus on systems and processes, not people.

This step benefits from team input. Share Claude's draft with the team and ask what's missing or mischaracterized.

Step 3: Extract Lessons (30 minutes)

From the contributing factors, extract lessons learned:

For each lesson:
- What we learned (one sentence)
- Evidence (which factor(s) taught us this)
- Is this new or something we already knew but didn't act on?
- How generalizable is this? (applies to this project only, or to how we work broadly)

Prioritize: which lessons, if acted on, would have the biggest impact on
preventing similar failures?

Step 4: Draft Action Items (30 minutes)

Convert the top lessons into action items:

For each action:
- What specifically changes (process, tooling, communication, planning)
- Owner (who is responsible for making this change)
- Deadline (when will this be implemented)
- How we verify (how do we know the change stuck)
- Scope: is this a one-time fix or an ongoing process change?

Keep it to 3-5 actions max. More than 5 means nothing gets done.
Distinguish between:
- Quick wins (can implement this week)
- Structural changes (need a project or process redesign)
- Monitoring (watch for recurrence, no action yet)

Step 5: Write the Post-Mortem Document (15 minutes)

Format the complete post-mortem:

1. Summary: What happened, in 2-3 sentences
2. Impact: Users affected, revenue impact, reputation impact
3. Timeline: Key events in chronological order
4. Contributing factors: Categorized, blameless
5. Lessons learned: Prioritized
6. Action items: Specific, owned, time-bound
7. Follow-up date: When we review whether actions were implemented

Tone: factual, blameless, forward-looking. This document exists to prevent
recurrence, not to assign fault.

Output

• Chronological event timeline
• Contributing factors categorized by type
• Prioritized lessons learned
• 3-5 specific, owned, time-bound action items
• Complete post-mortem document

Common Pitfalls

1. **Blame culture.** The fastest way to kill learning is to punish honesty. Post-mortems must be blameless. If people fear consequences, they won't share what went wrong. 2. **Too many action items.** 3-5 max. A post-mortem with 15 action items means none of them get done. Prioritize ruthlessly. 3. **No follow-up.** Schedule a review 30 days after the post-mortem to check: did we implement the actions? Did they work? This is where most post-mortems fail. 4. **Recency bias.** The most recent failure gets the most attention. But is it representative? Check whether this is a pattern or a one-off before over-investing in prevention. 5. **Only doing post-mortems for failures.** The best learning comes from near-misses too. If something almost went wrong but didn't, that's worth analyzing — you might not get lucky next time.

Related Skills

• [Stakeholder Alignment](../stakeholder-alignment/SKILL.md) — when post-mortem findings need executive action
• [Metrics Review](../metrics-review/SKILL.md) — monitoring for recurrence after implementing changes
• [Sprint & Release P