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. Show more

安装