Use when analyzing failures, outages, incidents, or negative outcomes, conducting blameless postmortems, documenting root causes with 5 Whys or fishbone diagrams, identifying corrective actions with owners and timelines, learning from near-misses, establishing prevention strategies, or when user mentions postmortem, incident review, failure analysis, RCA, lessons learned, or after-action review.
View on GitHubskills/postmortem/SKILL.md
January 24, 2026
Select agents to install to:
npx add-skill https://github.com/lyndonkl/claude/blob/main/skills/postmortem/SKILL.md -a claude-code --skill postmortemInstallation paths:
.claude/skills/postmortem/# Postmortem ## Table of Contents 1. [Purpose](#purpose) 2. [When to Use](#when-to-use) 3. [What Is It?](#what-is-it) 4. [Workflow](#workflow) 5. [Common Patterns](#common-patterns) 6. [Guardrails](#guardrails) 7. [Quick Reference](#quick-reference) ## Purpose Conduct blameless postmortems that transform failures into learning opportunities by documenting what happened, why it happened, impact quantification, root cause analysis, and actionable preventions with clear ownership. ## When to Use **Use this skill when:** ### Incident Context - Production outage, system failure, or service degradation occurred - Security breach, data loss, or compliance violation happened - Product launch failed, project missed deadline, or initiative underperformed - Customer-impacting bug, quality issue, or support crisis arose - Near-miss incident that could have caused serious harm (proactive postmortem) ### Learning Goals - Need to understand root cause (not just symptoms) to prevent recurrence - Want to identify systemic issues vs. individual mistakes - Must document timeline and impact for stakeholders or auditors - Aim to improve processes, systems, or practices based on failure insights - Building organizational learning culture (celebrate transparency, not blame) ### Timing - **Immediately after** incident resolution (while memory fresh, within 48 hours) - **Scheduled reviews** for recurring issues or chronic problems - **Quarterly reviews** of all incidents to identify patterns - **Pre-mortem** style: Before major launch, imagine it failed and write postmortem **Do NOT use when:** - Incident still ongoing (focus on resolution first, postmortem second) - Looking to assign blame or punish individuals (antithesis of blameless culture) - Issue is trivial with no learning value (reserved for significant incidents) ## What Is It? **Postmortem** is a structured, blameless analysis of failures that answers: - **What happened?** Timeline of events from detection to resolutio