debrieflisted

# Debrief The merge boundary is the one moment the whole arc of a piece of work — the plan, the wrong turns, the fix that landed — is still in the context window. Debrief mines it there, in the same turn, instead of reconstructing it later from transcripts. The skill is split in half on purpose: this file captures, [`LADDER.md`](LADDER.md) routes. Capture is per-merge and cheap; routing is batched, because a pattern is visible across ten debriefs and invisible in one. ## When this applies - A PR just merged — you merged it, or watched the merge land. Run the three questions now, before the next task starts. - `/debrief` by hand at any finished unit of work. - `/debrief ladder`: skip this file and run the pass in [`LADDER.md`](LADDER.md). ## When it does not - A lesson surfaces mid-task. That is one `insight` row via the **capture** skill, straight back to the work; the boundary is what makes a debrief a debrief. - The user wants learnings mined from the transcript and routed into skills in this session. That is the **reflect** skill. Debrief writes rows and defers routing. ## The three questions Answer from the session in your context window, not from logs. One line each. 1. **What worked?** An approach, an ordering, a check you would repeat in the same spot. 2. **What didn't?** The path abandoned, the correction the user had to make, the result that surprised you. 3. **What generalizes?** The insight that outlives this PR: a recipe, a gotcha, a rule the next session