Post-mortem

The canonical engineering record of a bug fix. Written after debugging lands a real fix, for other engineers (and future-you, who will have forgotten everything in 6 months). Code identifiers are welcome here — this is the artifact that lets the next person recover the mental model fast.

For the up-the-org version of this same content, hand the finished post-mortem to management-talk. They compose: post-mortem owns the engineering truth, management-talk reframes it for leadership.

When to invoke

• "/post-mortem"
• "write the post-mortem / postmortem / RCA / root-cause analysis"
• "document this fix" / "write up the root cause" / "close out this bug with a writeup"
• After a debug session has clearly landed a fix, proactively offer to draft one.

When NOT to use

• Bug not fixed yet, or fix not validated. A post-mortem of a hypothesis is misleading. Refuse and tell the user what's missing.
• Customer-visible outage / incident. Those need a separate incident report (timeline, blast radius, paging history, comms). This skill is bug-fix scope. Flag and confirm before producing one.
• Trivial fix (typo, obvious one-liner). The PR description is the record. Don't manufacture ceremony.