postmortem-writing

wshobson/agents

Write blameless postmortems with root cause analysis, timelines, and action items to drive organizational learning.

What is postmortem-writing?

This skill guides you through writing effective postmortems that focus on systems and processes rather than individual blame. Use it when conducting incident reviews, analyzing root causes with techniques like 5 Whys, and creating actionable follow-up items to prevent recurrence.

Structure postmortem documents with timeline, root cause analysis, and action items
Facilitate blameless postmortem meetings using a 60-minute meeting framework
Apply 5 Whys analysis to identify systemic root causes and contributing factors
Distinguish between blame-focused and blameless approaches to incident review
Create quick postmortems for minor incidents (SEV3) and comprehensive ones for major incidents
Identify and avoid anti-patterns like shallow analysis, unrealistic actions, and lack of follow-up

How to install postmortem-writing

npx skills add https://github.com/wshobson/agents --skill postmortem-writing

Claude Code

Cursor

Windsurf

Cline

How to use postmortem-writing

1.Determine if the incident meets postmortem criteria (SEV1/SEV2, customer-facing outage >15 min, data loss, security incident, or novel failure mode)
2.Draft the postmortem document within 1-2 days using the provided templates (full template, 5 Whys analysis, or quick postmortem format)
3.Schedule a postmortem meeting 3-5 days after the incident
4.Run the 60-minute facilitated meeting: opening (5 min), timeline review (15 min), analysis discussion (20 min), action items (15 min), closing (5 min)
5.Finalize the document and create tickets for action items with assigned owners and due dates
6.Track action item completion and review patterns across incidents quarterly

Use cases

Good for

Conducting post-incident reviews after SEV1/SEV2 outages or customer-facing incidents
Writing detailed postmortem documents with timeline, root cause, and systemic improvements
Facilitating team meetings to analyze what went wrong and identify learnings
Analyzing near-misses and novel failure modes to prevent future incidents
Creating actionable tickets and improvements from incident analysis

Who it's for

Incident commanders and on-call engineers
Engineering managers and team leads
DevOps and SRE teams
Product and platform teams conducting incident reviews
Organizations building blameless incident response culture

postmortem-writing FAQ

What's the difference between blame-focused and blameless postmortems?

Blame-focused asks 'who caused this?' and punishes individuals, creating fear and hiding information. Blameless asks 'what conditions allowed this?' and improves systems, building psychological safety and organizational learning.

When should I write a postmortem?

Write postmortems for SEV1/SEV2 incidents, customer-facing outages longer than 15 minutes, data loss or security incidents, near-misses that could have been severe, novel failure modes, and incidents requiring unusual intervention.

How do I use the 5 Whys technique?

Start with the problem statement, then ask 'why' five times, providing evidence for each answer. This uncovers systemic root causes rather than surface-level explanations. Identify primary, secondary, and tertiary causes, then propose systemic improvements.

What should action items look like?

Action items must be specific, achievable, and assigned to an owner with a due date. Avoid busywork; focus on meaningful improvements that address root causes. Track completion and verify actions were actually done.

How do I keep the postmortem blameless when someone clearly made a mistake?

Redirect focus from the person to the system. Instead of 'the developer made a mistake,' ask 'what conditions allowed this mistake to reach production?' (e.g., missing tests, inadequate code review, insufficient documentation). This identifies systemic improvements.

Full instructions (SKILL.md)

Source of truth, from wshobson/agents.

name: postmortem-writing description: Write effective blameless postmortems with root cause analysis, timelines, and action items. Use when conducting incident reviews, writing postmortem documents, or improving incident response processes.

Postmortem Writing

Comprehensive guide to writing effective, blameless postmortems that drive organizational learning and prevent incident recurrence.

When to Use This Skill

Conducting post-incident reviews
Writing postmortem documents
Facilitating blameless postmortem meetings
Identifying root causes and contributing factors
Creating actionable follow-up items
Building organizational learning culture

Core Concepts

1. Blameless Culture

Blame-Focused	Blameless
"Who caused this?"	"What conditions allowed this?"
"Someone made a mistake"	"The system allowed this mistake"
Punish individuals	Improve systems
Hide information	Share learnings
Fear of speaking up	Psychological safety

2. Postmortem Triggers

SEV1 or SEV2 incidents
Customer-facing outages > 15 minutes
Data loss or security incidents
Near-misses that could have been severe
Novel failure modes
Incidents requiring unusual intervention

Quick Start

Postmortem Timeline

Day 0: Incident occurs
Day 1-2: Draft postmortem document
Day 3-5: Postmortem meeting
Day 5-7: Finalize document, create tickets
Week 2+: Action item completion
Quarterly: Review patterns across incidents

Templates and detailed worked examples

Full template library and detailed worked examples live in references/details.md. Read that file when you need the concrete templates.

References


### Template 2: 5 Whys Analysis

```markdown
# 5 Whys Analysis: [Incident]

## Problem Statement

Payment service experienced 47-minute outage due to database connection exhaustion.

## Analysis

### Why #1: Why did the service fail?

**Answer**: Database connections were exhausted, causing all new requests to fail.

**Evidence**: Metrics showed connection count at 100/100 (max), with 500+ pending requests.

---

### Why #2: Why were database connections exhausted?

**Answer**: Each incoming request opened a new database connection instead of using the connection pool.

**Evidence**: Code diff shows direct `DriverManager.getConnection()` instead of pooled `DataSource`.

---

### Why #3: Why did the code bypass the connection pool?

**Answer**: A developer refactored the repository class and inadvertently changed the connection acquisition method.

**Evidence**: PR #1234 shows the change, made while fixing a different bug.

---

### Why #4: Why wasn't this caught in code review?

**Answer**: The reviewer focused on the functional change (the bug fix) and didn't notice the infrastructure change.

**Evidence**: Review comments only discuss business logic.

---

### Why #5: Why isn't there a safety net for this type of change?

**Answer**: We lack automated tests that verify connection pool behavior and lack documentation about our connection patterns.

**Evidence**: Test suite has no tests for connection handling; wiki has no article on database connections.

## Root Causes Identified

1. **Primary**: Missing automated tests for infrastructure behavior
2. **Secondary**: Insufficient documentation of architectural patterns
3. **Tertiary**: Code review checklist doesn't include infrastructure considerations

## Systemic Improvements

| Root Cause    | Improvement                       | Type       |
| ------------- | --------------------------------- | ---------- |
| Missing tests | Add infrastructure behavior tests | Prevention |
| Missing docs  | Document connection patterns      | Prevention |
| Review gaps   | Update review checklist           | Detection  |
| No canary     | Implement canary deployments      | Mitigation |

Template 3: Quick Postmortem (Minor Incidents)

# Quick Postmortem: [Brief Title]

**Date**: 2024-01-15 | **Duration**: 12 min | **Severity**: SEV3

## What Happened

API latency spiked to 5s due to cache miss storm after cache flush.

## Timeline

- 10:00 - Cache flush initiated for config update
- 10:02 - Latency alerts fire
- 10:05 - Identified as cache miss storm
- 10:08 - Enabled cache warming
- 10:12 - Latency normalized

## Root Cause

Full cache flush for minor config update caused thundering herd.

## Fix

- Immediate: Enabled cache warming
- Long-term: Implement partial cache invalidation (ENG-999)

## Lessons

Don't full-flush cache in production; use targeted invalidation.

Facilitation Guide

Running a Postmortem Meeting

## Meeting Structure (60 minutes)

### 1. Opening (5 min)

- Remind everyone of blameless culture
- "We're here to learn, not to blame"
- Review meeting norms

### 2. Timeline Review (15 min)

- Walk through events chronologically
- Ask clarifying questions
- Identify gaps in timeline

### 3. Analysis Discussion (20 min)

- What failed?
- Why did it fail?
- What conditions allowed this?
- What would have prevented it?

### 4. Action Items (15 min)

- Brainstorm improvements
- Prioritize by impact and effort
- Assign owners and due dates

### 5. Closing (5 min)

- Summarize key learnings
- Confirm action item owners
- Schedule follow-up if needed

## Facilitation Tips

- Keep discussion on track
- Redirect blame to systems
- Encourage quiet participants
- Document dissenting views
- Time-box tangents

Anti-Patterns to Avoid

Anti-Pattern	Problem	Better Approach
Blame game	Shuts down learning	Focus on systems
Shallow analysis	Doesn't prevent recurrence	Ask "why" 5 times
No action items	Waste of time	Always have concrete next steps
Unrealistic actions	Never completed	Scope to achievable tasks
No follow-up	Actions forgotten	Track in ticketing system