Skill

Skill: post-mortem

Facilitate a blameless post-mortem after a delivery incident, missed release, or production outage. Focus on systemic causes and preventive actions, not individual blame.

Install

npx claudepluginhub devmuslim/pdm-skills --plugin pdm-metrics-reporting

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Facilitate a blameless post-mortem after a delivery incident, missed release, or production outage. Focus on systemic causes and preventive actions, not individual blame.

SKILL.md

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

139.0k

claude-opus-4-5-migration

2 files

Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.

claude-opus-4-5-migration

83.2k

bmad-brainstorming

11 files

Facilitates interactive brainstorming sessions using diverse creative techniques and ideation methods. Activates when users say 'help me brainstorm' or 'help me ideate'.

bmad-pro-skills

43.8k

Stats

Parent Repo Stars0

Parent Repo Forks0

Last CommitMar 9, 2026

Actions

View Source View Plugin View on GitHub View README

Skill: post-mortem

Purpose

Facilitate a blameless post-mortem after a delivery incident, missed release, or production outage. Focus on systemic causes and preventive actions, not individual blame.

When to Use

After a production incident
After a missed release date
After a quality failure reaches production
After a major scope cut under pressure

Framework: Blameless Post-Mortem

Principle: Systems Thinking

"The goal is not to find who is at fault. The goal is to understand what in the system allowed this to happen — and how to fix it."

Step 1 — Gather Incident Data

Ask for:

What happened? (brief description)
When was it detected?
What was the customer/business impact?
How long did it last?
How was it resolved?
Who was involved in the response?

Step 2 — Timeline Reconstruction

Build a factual timeline:

Time	Event	Who Noticed	Action Taken
T+0	Incident begins	Monitoring alert	...
T+15m	Team notified	On-call engineer	...
T+45m	Root cause identified	...	...
T+2h	Fix deployed	...	...
T+2h30m	Incident resolved	...	...

Step 3 — Five Whys Analysis

Start with the symptom and ask "Why?" five times:

Why did X happen?
Why did Y allow X?
Why was Y not prevented?
Why did the process not catch Y?
Why does the process have this gap?

Root cause = the answer to the 5th Why.

Step 4 — Contributing Factors

Classify contributing factors:

Process — Gaps in how we work
Technical — System or tooling failures
Communication — Information that didn't reach the right people in time
Knowledge — Skills or awareness gaps

Step 5 — Action Items

Action	Owner	Due Date	Priority
...	...	...	P0/P1/P2

Each action should be:

Specific and measurable
Assigned to one person
Have a clear deadline
Directly address a root cause or contributing factor

Step 6 — Post-Mortem Summary (shareable)

Incident: One sentence
Impact: Duration, users affected, business impact
Root Cause: One sentence
Resolution: What fixed it
Key Actions: Top 3 action items

Output Format

Timeline table
Five Whys analysis
Action items table
Shareable summary (suitable for Confluence or Slack)
Suggested next command: /lessons-learned or /risk-register