session-postmortem
Use when a past or running agent session went wrong and the operator wants to know why (repeated work, ignored plan, a skill that did not fire, slow or costly): pin the problem down, read the transcri
Files1
View on GitHubSKILL.mdskills/session-postmortem/SKILL.md
GitHubsession-postmortem
Cross-cutting (WORKFLOW.md §2), applied to a session rather than a product. It reports what happened,
with evidence; it does not fix, export or file anything.
Core rule: every finding cites path:line. No citation, no finding. Every number comes from the
transcript or from a command that was run, never from memory.
When
After a session that repeated work, ignored its plan, stalled, skipped an expected skill, or cost more than expected, and someone wants the cause.
Steps
- Intake, one question at a time, until there is a statement naming the session, the turn range if known, what was expected, what happened, and the observable that matters (wall-clock, tokens, a repeated action). "It took too long" is a complaint, not a statement. Nothing below starts before the operator has answered; if they are away, write the questions and stop.
- Locate the transcripts. Resolve each session to absolute paths. Confirm a past session by quoting its first prompt and timestamp. List every candidate rejected, with the reason, or write "none". Enumerate subagent transcripts too; in those, the "user" is the parent agent.
- Context safety, every file, every time. One record can be a megabyte.
- Measure first (
wc -lc, list lines over a size threshold). - Never print a transcript to read it. Get line numbers and counts first, then small fields from named lines, cut to a few hundred characters.
- Anything longer than that for one record means the slice was too wide.
- Measure first (
- Analyse in seven dimensions, in parallel where the transcript is long, splitting by turn range:
- timeline of skills fired and not fired;
- adherence to the plan, compaction points first;
- repeated work;
- stumbles (errors, retries, dead ends);
- quality evidence (was success shown or asserted);
- conflicts between requests;
- cost and time.
Discard any returned finding without
path:line.
- Report: the verdict first, then findings in the order of the operator's complaint, each with its citation, then what could not be determined.
Output / checkpoint
No pipeline checkpoint. A report with cited findings and an explicit coverage note (what was and was not read).
Guardrails
- Read-only. Never modify, move or delete a session file.
- Operator words only. Hook output, system reminders and tool results are not the operator's prompts.
- Report, do not diagnose the framework. State what the transcript shows; whoever triages decides whether a block changes. No advice unless asked.
- No bundle export, no issue drafting, no scrubbing: out of scope here by choice.
Origin
Mechanism rewritten from the diagnosing-superpowers skill of the superpowers collection (MIT), read
2026-10-02: the intake-before-analysis gate, rejected-candidate listing, the seven analysis dimensions, the
path:line rule and the transcript context-safety procedure. Left out: bundle export, scrubbing, issue
writing and similar-session search. Wording and structure are ours. Not run on real work.