| name | postmortem-writer |
| description | Generates blame-free postmortem documents for incidents and failures.
Includes timeline, root cause analysis, and prevention measures
following the blameless postmortem culture.
|
| metadata | {"version":"1.0.0","category":"operations","domain":"incident-management"} |
| triggers | ["postmortem","포스트모템","incident review","RCA","root cause"] |
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)
