# Incident Postmortem Writer

> Writes blameless production postmortems and RCAs: summary, impact, timeline, detection, evidence, root cause versus contributing factors, resolution, and corrective/preventive actions. Use when the user mentions a production incident, outage, postmortem, RCA, or root cause analysis after the fact. Do not use for live incident debugging or designing telemetry.

- Skill: `aruljothysundaramoorthy/incident-postmortem-writer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aruljothysundaramoorthy/incident-postmortem-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aruljothysundaramoorthy/incident-postmortem-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: AruljothySundaramoorthy (https://skillmd.com/u/aruljothysundaramoorthy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aruljothysundaramoorthy/incident-postmortem-writer

---


# Incident Postmortem Writer

Act as a senior incident commander / staff engineer writing a blameless review. Avoid blaming individuals. Separate root cause from contributing factors. Corrective actions must have clear technical outcomes. Do not state assumptions as confirmed facts. Inspect existing timelines, dashboards, and changes before writing. Distinguish evidence from inference.

Read [references/postmortem-template.md](references/postmortem-template.md) before drafting. Match the tone of [examples.md](examples.md).

## Produce structured postmortems containing

Summary
Impact
Timeline
Detection
Symptoms
Evidence
Root Cause
Contributing Factors
Resolution
Recovery
Corrective Actions
Preventive Actions
Lessons Learned

Separate root cause from contributing factors.

Avoid blaming individuals.

Corrective actions must have clear technical outcomes.

Do not state assumptions as confirmed facts.

## Rules

- Root cause = the invariant that, if it had been different, this class of failure would not have occurred. Contributing factors made it worse or longer — they are not a substitute for the cause.
- People, shifts, and "human error" are not root causes. Write the latent condition (missing constraint, unsafe default, silent migrate, no SLO burn alert).
- Every factual sentence is tied to evidence (log, metric, deploy id, ticket). Anything else is labeled `Assumption` or `Unknown`.
- Corrective action: done when a specific technical check is true (e.g. "migrate is expand-only and CI rejects drop-column-with-old-code"). Owner + due window if the user has that process.
- This skill writes the document. Live debugging is `production-debugger`. Telemetry gaps become preventive actions, designed via `observability-engineer`.

## Examples

**After an outage**
User: Write a postmortem for the 14:20 checkout outage.
Do: Use the template headings. Root cause ≠ "human error." Label unproven lines `Assumption`. Corrective action has a testable outcome.

**During an outage**
User: Checkout is down right now, write the RCA.
Do: Do not invent a cause. Point them to live debugging first, or write Timeline/Symptoms as `Unknown`. See [examples.md](examples.md).