post-mortemlisted

# Post-Mortem `debugging` finds why the code broke. This finds why the break *escaped* — which gate should have caught it and didn't — and converts that into a change that makes the whole class impossible next time. The deliverable is not a fix; it is a stronger gate. Be honest about what this is: a structured reasoning pass, not a deterministic gate itself. Its value lives entirely in the **gates it produces** — a test, a check, an assertion — not in the reflection. A post-mortem that ends in resolutions instead of gates changed nothing. ## When to use - A failure reached production, or a defect surfaced far downstream of where it was introduced. - A unit of work went badly enough to be worth learning from (a retrospective). - **Skip** for a bug you simply reproduce and fix — that is `debugging`. This skill starts *after* the cause is known and asks why it got past everyone. ## Procedure 1. **Reconstruct the timeline from artifacts, not memory.** Walk the commits, CI runs, logs, and review history: when was the defect introduced, when did each check run, when was it noticed? Memory rewrites history into a tidy story; the artifacts don't. 2. **Find the cause of the escape, not the bug.** The code cause is `debugging`'s job. Here, list every gate the change passed through — spec, review, tests, CI, release — and for each ask: was it *missing*, *present but too weak*, or *skipped*? The escape is wherever a gate should have stood and didn't. 3. **Drive each finding to a