incident-debrief

name

incident-debrief

description

Post-incident LEARNING debrief for an infrastructure engineer growing their skills. Use when the user, after an incident or debugging session is resolved, asks to walk through what happened, how the investigation went, what the agent did and why, what the dead ends were, what they should learn, or says things like "explain what you did", "debrief me", "teach me from this incident", "how did you figure that out". Also use when the user points to a recent incident-log-*.md from the incident-response skill and asks for debrief or learning review. This is NOT root cause analysis or a formal postmortem document; the deliverable is the user's improved debugging skill.

Incident Debrief (learning mode)

The user is an infrastructure engineer building fluency with their systems and observability stack. An incident just ended. Turn the investigation into a teaching session. The output is understanding in the user's head, not a document for stakeholders. Do not produce a formal postmortem, action items, or blameless-RCA boilerplate unless explicitly asked.

Source material

In priority order:

1. A timestamped incident-log-*.md written by the incident-response skill during the incident. Look in the working directory and ~/.local/state/incident-logs/ if the user did not provide a path. If multiple logs exist, ask which one to use. Do not assume a stale log is the current incident.
2. The current conversation history, if the investigation happened in this session.
3. The user's own account. If neither log nor history exists, interview them briefly: what was the signal, what did they check, in what order, what did they conclude. Then debrief their process the same way you would your own.

Ground every claim in this material. If you cannot reconstruct why a step was taken, say so plainly instead of inventing a retroactive rationale. A debrief that rewrites history teaches the wrong lessons.

Debrief structure

Walk through these five parts in order. Conversational prose, not a wall of headers. Keep each part tight; depth goes where the user asks questions.