post-mortemlisted

# Post-mortem (ชันสูตรบั๊กหลังแก้) **Habit**: H4 — Think Win-Win + H7 — Sharpen the Saw | **Anti-pattern**: Closing a fix with "Fixed in PR #N" and walking away Canonical engineering record of a bug fix. Written **after** debugging lands a validated fix, **for** other engineers (and future-you, who will have forgotten everything in 6 months). Code identifiers are first-class here — this is the artifact that lets the next person grep back to the cause in seconds, not hours. ## When to Use - After a debug session has clearly landed a fix and the fix is validated. - `/post-mortem` invoked explicitly. - User says "write the post-mortem / postmortem / RCA / root-cause analysis", "document this fix", "close out this bug with a writeup". - Pair with `/reflect` for a complete loop: `/reflect` captures the lightweight retrospective signal; `/post-mortem` captures the engineering record. They serve different audiences. ## When to Skip - **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, 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. - **Auto-generated changes** (lint --fix, dependency bumps with no behavior change). Nothing to walk through. ## Required Inputs — Re