Post-Mortem
Use this skill only in the top-level session. It needs the conversation history and Jörn's framing.
The output is advisory. Do not edit files, create archival notes, update skills, or create commits unless Jörn separately asks for edits in the same turn.
Operating model
Prefer concrete operational failures over abstract workflow stories.
- Name what actually went wrong first: a prompt ambiguity, a tool action, a bad edit, a missed question, a stale instruction, a wasted rerun, or a preventable user interruption.
- Treat process theories as secondary. Use them only when they explain an observed failure.
- Do not invent a new "problem" unless it caused concrete harm in the session.
- If a proposed harness change would not have prevented or shortened a real failure, treat it as optional polish or omit it.
- Separate:
- actual problem
- contributing factor
- optional wording cleanup
Good reflection:
- "The worker edited root
main instead of its assigned worktree; strengthen the worker cwd contract."
- "The agent preserved obvious leaked tracked junk too long; ask for immediate revert once confidence is high."
Bad reflection:
- "The session lost alignment with its phase energy."
- "A generalized mode-transition framework may be needed."
Use wording like this only if you can point to a concrete failure it would have prevented.
Questions
Answer only the questions that apply:
- What happened? Name the concrete prompt, tool action, file, or instruction surface.
- What slowed the session down?
- Which instruction, skill trigger, subagent prompt, or repo convention contributed?
- Where did Jörn spend time that an agent could have spent?
- What future agent behavior should change?
- What positive behavior should future agents preserve or repeat?
- What wording or structural changes should a future guide-editing session try?
- What conflicts, stale assumptions, or risks should that future session check?
- What alternatives were considered and why were they not preferred?
Output
Use this structure:
- Incident, friction, or positive pattern: one short paragraph.
- Likely cause: concrete instruction, prompt, skill wording, tool action, or process mismatch.
- Suggested changes: bullets that Jörn can approve, reject, or copy into a focused editing session. Each bullet must say what concrete failure it addresses.
- Checks for the editing session: conflicts, files to inspect, and validation commands.
Keep it concise. Do not turn reflection into implementation.
Do not pad the report with governance language, abstract phase models, or speculative architecture unless they are clearly tied to an observed failure.
1---2name: post-mortem3description: Top-level, Jörn-invoked post-session reflection and blameless positive or negative incident analysis. Use only when Jörn explicitly invokes `$post-mortem` or asks the top-level session for a post-session reflection; do not use from subagents, routine reviews, pre-merge checks, or normal task completion.4---56# Post-Mortem78Use this skill only in the top-level session. It needs the conversation history and Jörn's framing.910The output is advisory. Do not edit files, create archival notes, update skills, or create commits unless Jörn separately asks for edits in the same turn.1112## Operating model1314Prefer concrete operational failures over abstract workflow stories.1516- Name what actually went wrong first: a prompt ambiguity, a tool action, a bad edit, a missed question, a stale instruction, a wasted rerun, or a preventable user interruption.17- Treat process theories as secondary. Use them only when they explain an observed failure.18- Do not invent a new "problem" unless it caused concrete harm in the session.19- If a proposed harness change would not have prevented or shortened a real failure, treat it as optional polish or omit it.20- Separate:21 - actual problem22 - contributing factor23 - optional wording cleanup2425Good reflection:26- "The worker edited root `main` instead of its assigned worktree; strengthen the worker cwd contract."27- "The agent preserved obvious leaked tracked junk too long; ask for immediate revert once confidence is high."2829Bad reflection:30- "The session lost alignment with its phase energy."31- "A generalized mode-transition framework may be needed."32 Use wording like this only if you can point to a concrete failure it would have prevented.3334## Questions3536Answer only the questions that apply:37381. What happened? Name the concrete prompt, tool action, file, or instruction surface.392. What slowed the session down?403. Which instruction, skill trigger, subagent prompt, or repo convention contributed?414. Where did Jörn spend time that an agent could have spent?425. What future agent behavior should change?436. What positive behavior should future agents preserve or repeat?447. What wording or structural changes should a future guide-editing session try?458. What conflicts, stale assumptions, or risks should that future session check?469. What alternatives were considered and why were they not preferred?4748## Output4950Use this structure:51521. **Incident, friction, or positive pattern:** one short paragraph.532. **Likely cause:** concrete instruction, prompt, skill wording, tool action, or process mismatch.543. **Suggested changes:** bullets that Jörn can approve, reject, or copy into a focused editing session. Each bullet must say what concrete failure it addresses.554. **Checks for the editing session:** conflicts, files to inspect, and validation commands.5657Keep it concise. Do not turn reflection into implementation.58Do not pad the report with governance language, abstract phase models, or speculative architecture unless they are clearly tied to an observed failure.
JoernStoehler