Postmortem
Open-source Claude skills for Program Management in product development — charters, status reports, RAID logs, roadmaps, launch readiness, retros, postmortems, OKRs & more.
npx -y skills add janellecipriano/pm-skills --skill postmortemAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Run a blameless postmortem / incident review — timeline, impact, root cause analysis, and corrective actions. Use when the user says "postmortem", "incident review", "RCA", "root cause analysis", "what happened with the outage", or wants to turn an incident into a structured, blameless writeup with preventive actions.
SKILL.md
2.3 KB, as published. Nobody here has run it
Postmortem (Blameless Incident Review)
Turn an incident into learning and prevention — focused on systems and process, never on blaming individuals.
When to use
- After an outage, regression, data issue, security event, or significant miss.
For sprint/project reflection (not incidents) use retrospective.
Principles
- Blameless. Assume everyone acted reasonably with the information they had. Fix systems, not people. Replace "X made a mistake" with "the system allowed X to happen."
- Facts first. Build the timeline from evidence (logs, alerts, messages) before drawing conclusions.
- Root cause, not first cause. Use the 5 Whys / contributing-factors analysis to get past the proximate trigger.
- Actions must prevent recurrence, be owned, and be dated.
Inputs to gather
- What happened, when detected, when resolved; severity and who/what was impacted.
- The timeline of events and the response.
- Logs/notes if available.
Process
- Write a summary: what happened, impact (users/duration/scope), severity.
- Build a timeline (UTC or stated TZ): detection → diagnosis → mitigation → resolution. Note time-to-detect and time-to-resolve.
- Analyze root cause(s) and contributing factors (5 Whys).
- Note what went well and what made it worse (detection gaps, slow rollback, unclear ownership).
- Define corrective actions: preventive + detective, each with owner, due date, priority.
- Capture lessons learned.
Output format
# Postmortem — {{incident}} · {{date}}
**Severity:** {{SEV}} · **Impact:** {{users/scope/duration}} · **Status:** Resolved
## Summary
{{2–4 sentences}}
## Timeline
| Time | Event |
## Root cause & contributing factors
{{5 Whys / analysis}}
## What went well / what went poorly
- ...
## Action items
| Action | Type (prevent/detect) | Owner | Due | Priority |
Keep tone neutral and factual throughout.