postmortem
reconstruct what broke, why, and the one change that prevents the next one
A timeline in facts, the impact in the affected person's terms, the cause followed until it is a system and not a person, and the one change that prevents the next one.
structure generate skill postmortemSkill — postmortem
Invoke in any agent conversation with /postmortem. The steps below are a starting opinion, and
they are what runs — edit them until they describe the write-up this company would want after a bad
week.
When to use. After anything a customer noticed, anything that cost a day, and anything that has now happened twice.
Steps.
- Timeline first, facts only: what happened and when, in times a reader can follow.
- Impact, in the affected person's terms — who, for how long, what they could not do.
- The cause, followed until it stops being a person and starts being a system. Stop when the next "why" would be a guess, and say that you stopped there.
- What made it hard to see, and separately, what made it hard to fix. They are rarely the same answer, and the first one is usually the more expensive.
- One change, specific, with an owner and a date. Prefer the change that makes the whole class impossible over the one that fixes this instance.
- No blame language. People appear as who did what, never as who was at fault — the account you get next time depends on it.
- File it dated, and link it from whatever standard or runbook it changed. A postmortem that changes no document is a story.
---
type: skill
name: postmortem
description: reconstruct what broke, why, and the one change that prevents the next one
standing: draft
owner: "{{owner}}"
updated: "{{date}}"
---
# Skill — postmortem
_Invoke in any agent conversation with `/postmortem`. The steps below are a starting opinion, and
they are what runs — edit them until they describe the write-up this company would want after a bad
week._
**When to use.** After anything a customer noticed, anything that cost a day, and anything that has
now happened twice.
**Steps.**
1. Timeline first, facts only: what happened and when, in times a reader can follow.
2. Impact, in the affected person's terms — who, for how long, what they could not do.
3. The cause, followed until it stops being a person and starts being a system. Stop when the next
"why" would be a guess, and say that you stopped there.
4. What made it hard to see, and separately, what made it hard to fix. They are rarely the same
answer, and the first one is usually the more expensive.
5. One change, specific, with an owner and a date. Prefer the change that makes the whole class
impossible over the one that fixes this instance.
6. No blame language. People appear as who did what, never as who was at fault — the account you get
next time depends on it.
7. File it dated, and link it from whatever standard or runbook it changed. A postmortem that
changes no document is a story.
type: skill
name: postmortem
about: "A timeline in facts, the impact in the affected person's terms, the cause followed until it is a system and not a person, and the one change that prevents the next one."
version: "0.1.0"