Postmortem writer

Skill Dokkabei97/forged-claude-code/skills/coo/postmortem-writer

Generates blame-free postmortem documents for incidents and failures. Includes timeline, root cause analysis, and prevention measures following the blameless postmortem culture.From its SKILL.md

Install

npx -y skills add Dokkabei97/forged-claude-code --skill postmortem-writer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 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.

SKILL.md

3.5 KB, as published. Nobody here has run it

Postmortem Writer - Blameless Incident Review

Overview

Documents failures so the team learns and the same mistake never happens twice. Blame people → they hide mistakes. Fix systems → they prevent mistakes.

1. When to Apply

Trigger	Behavior
Production incident resolved	Full postmortem template
Project/launch failure	Project postmortem
"postmortem", "RCA"	Interactive postmortem builder

2. Postmortem Template

# Postmortem: [Incident Title]

| Field | Value |
|-------|-------|
| **Date** | YYYY-MM-DD |
| **Severity** | P0 (Critical) / P1 (Major) / P2 (Minor) |
| **Duration** | [Start time] → [Resolution time] ([N] hours) |
| **Impact** | [Users affected, revenue lost, SLA breached] |
| **Author** | [Name] |
| **Reviewers** | [Names] |
| **Status** | Draft / Reviewed / Action Items Complete |

---

## Summary
[2-3 sentences: what happened, impact, how it was resolved]

## Timeline (All times in KST/UTC)
| Time | Event |
|------|-------|
| HH:MM | [First sign of issue] |
| HH:MM | [Alert triggered / User report] |
| HH:MM | [Investigation started by @name] |
| HH:MM | [Root cause identified] |
| HH:MM | [Fix deployed] |
| HH:MM | [Service fully restored] |

## Root Cause Analysis

### What Happened
[Detailed technical explanation of the failure chain]

### 5 Whys
1. **Why** did the service go down? → [Answer]
2. **Why** did that happen? → [Answer]
3. **Why** did that happen? → [Answer]
4. **Why** did that happen? → [Answer]
5. **Why** did that happen? → [Root cause]

### Contributing Factors
- [Factor 1 — not the root cause but made it worse]
- [Factor 2]

## What Went Well
- [Quick detection / response]
- [Effective communication]
- [Rollback worked as designed]

## What Went Poorly
- [Delayed detection]
- [Missing runbook]
- [Communication gaps]

## Action Items
| # | Action | Owner | Priority | Due | Status |
|---|--------|-------|----------|-----|--------|
| 1 | [Prevention measure] | @name | P0 | [date] | ⬜ |
| 2 | [Detection improvement] | @name | P1 | [date] | ⬜ |
| 3 | [Process change] | @name | P2 | [date] | ⬜ |

## Lessons Learned
- [Key insight for the team]

---
*This is a blameless postmortem. We focus on systems, not individuals.*

3. Blameless Culture Rules

No "who" — focus on "what" and "how"
Assume good intent — people made the best decision with available info
Fix systems — humans will always make mistakes; design systems that catch them
Share openly — postmortems are learning opportunities, not punishments
Follow through — track action items to completion

4. Tool Coordination

Tool	Purpose
Write	Generate postmortem documents
Read	Reference previous incidents, runbooks

5. Boundaries

Will:

Generate structured postmortem documents
Guide root cause analysis (5 Whys)
Enforce blameless language
Track action items from incidents

Will Not:

Investigate actual production incidents
Access logs, metrics, or monitoring systems
Assign blame to individuals
Replace real-time incident response (use runbook for that)