Post-Mortem

Produce a rich retrospective of the current live session by introspecting your own working memory — the reasoning, decisions, dead-ends, and token spend that only exist in this context, not in any file. The gold-standard output is honest, root-caused, quantified where possible, and ends in a reusable playbook.

This is introspection, NOT log-parsing. The payload — "I trusted the fork's summary, it had dropped 2 lines, I lost 15 min, lesson: grep the source first" — lives only in context. A log parser sees Bash ran 110×; it cannot see that 4 of those were you re-writing the same decoder. Do NOT read session JSONL transcripts. Read your own memory of what happened.

Output: a timestamped file post-mortem-YYYYMMDDHHmm.md (see step 1) + a 5-line spoken summary in chat. Always full — every core section, every qualifying session.

Distinct from /save-context (forward-looking resume state) and /instruct-compact (ephemeral compaction steering). This is a backward-looking debrief for learning, meant to be read by a human later.

When to Use

• End of a long (30min+) or multi-phase session, a hard problem solved, or sub-agents/forks were spawned.
• User says: "post-mortem", "retrospective", "session retro", "debrief", "what did we learn", "write up this session".
• Skip the ritual for trivial sessions: if it was a greeting or a one-file fix, say "Session is light — a post-mortem adds little" and write a 3-line note instead of the full ceremony.

Gotchas — the two rules that make or break the report

These are non-obvious and counter your defaults; violating either makes the report worthless.