Use postmortem-generator

Write a blameless incident postmortem from the raw material (chat scrollback, alert history, timeline, notes) for the audience and length the user names

Write a blameless incident postmortem from the raw material (chat scrollback, alert history, timeline, notes) for the audience and length the user names — the cause stated as the change and the gap that let it through, never a person even when the notes name one; who or what noticed first and how late; known kept apart from still-unknown; and follow-up actions that close the gap. Invents no times, figures, owners or severities. Use after an incident or outage when the user needs a postmortem, RCA, incident review, a plain explanation for a non-technical reader, or "lessons learned" doc.

Install it

npx skilldrop-cli install postmortem-generator                 # Claude Code, your user folder
npx skilldrop-cli install postmortem-generator --project       # Claude Code, this repo
npx skilldrop-cli install postmortem-generator --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the SRE / on-call pack: --pack sre-oncall installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Write a blameless postmortem for this incident"
• "Turn this pager timeline and Slack thread into a postmortem"
• "We resolved the outage — document what happened and why"
• "Generate the incident review doc with impact and action items"

Requests like these belong to a different skill, so it shouldn't answer them:

• "We're still in the incident — draft the customer update"
• "Extract the decisions and owners from this thread"
• "Write the runbook so this is handled better next time"

If another skill answers instead, ask for this one by name: "use postmortem-generator".

Check what you get

A good result:

• No person is named as a cause. Roles appear in response actions only, including when the user's notes name someone.
• Who or what noticed first is stated, with the gap to the first alert when the material gives both times.
• Known and still-open are kept apart.
• Causes are conditions, not "human error", and come only from the material.
• Every action is checkable, and has an owner only if the material named one.
• Nothing is invented: no figures, times, severities, owners or counts beyond the input.
• The length and format are the ones asked for, and the document has no placeholders.

Use something else when

• During the incident — mitigate first; live updates to stakeholders are incident-comms
• A performance-management record — the document is blameless by design; using it to blame kills honest reporting
• A project retrospective with no production incident
• Writing the runbook itself — hand the runbook changes to runbook-generator

Where a loop runs it

• Stage learn of the operate loop, where gate G4 decides

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: incident-comms, runbook-generator

Edit this page on GitHub · View source