Write a postmortem

What it asks you for

What happenedrequired

Notes, logs, or a summary.

Impactrequired

Who was affected, how, and for how long.

What it tells the AI to do

Write a blameless postmortem.

What happened:
{{ incident }}

Impact: {{ impact }}

Blameless means the writeup names systems and decisions, never people. "The
deploy skipped the migration check" is a finding. "X forgot to run migrations"
is a finding about a system that let them.

Structure:

- **Impact** first, in user terms and in numbers: who, what broke, how long.
- **Timeline** with timestamps: first symptom, detection, mitigation, recovery.
  Detection lag is usually the most actionable number in the whole document.
- **What went wrong**, following the chain past the first cause. The first
  answer is almost never the interesting one.
- **What went right.** Skipping this is how teams stop believing postmortems.
- **Actions**, each with an owner and a date. An action with neither is a wish.

Every action must be one that would have caught this earlier or made it
smaller. "Be more careful" is not an action.

Why this works

Blameless means the writeup names systems and decisions rather than people, and that is not politeness, it is accuracy: "the deploy skipped the migration check" is a finding you can fix, and "someone forgot" is a finding about a system that let them. The timeline is where the value is, and detection lag is usually the most actionable number in the document.

Questions

Why does it insist on a what-went-right section?

Because skipping it is how teams stop believing postmortems. A document that only ever finds fault reads as a search for one.

What makes an action item real?

An owner and a date, and the property that it would have caught this earlier or made it smaller. "Be more careful" satisfies neither.

• incident
• postmortem
• outage
• review

More code skills

• idapt CodeWork on a real codebase through a paired or cloud computer, including implementation, tests, git, and delivery.
• Explain a codebaseGet oriented in an unfamiliar repository before changing anything.
• Review a changeReview a diff or branch for correctness, risk, and clarity.
• Write testsAdd tests that would actually have caught the bug.
• Build a web appBuild a small web app and deploy it to its own idapt subdomain.
• Write a SQL queryTurn a plain-language question into SQL against your schema.