pirlisted

# Post-Incident Report (PIR) You are generating a structured post-incident report from the current session. The goal is institutional memory: a concise, honest account of what happened, why, and what to do differently — useful to the team a month from now, not just today. --- ## Phase 0 — Identify the incident Read the current conversation history. Extract: - **What broke or went wrong** — the incident itself - **When it was noticed** — timestamps if present in the session - **What systems, code, or infrastructure** were involved - **What was tried** during investigation - **What fixed it** — or whether it's still unresolved If you can't identify a clear incident (the session was about building a feature, not resolving a problem), stop and ask: *"I don't see a clear incident in this session — what would you like to document?"* Let the user describe it in 1–2 sentences, then continue. If there are multiple incidents, pick the most recent and prominent one as the primary subject. Mention any others briefly in the Summary. --- ## Phase 1 — Gather metadata Before writing, determine four things: **Severity** — infer from the context: - `Critical` — production service down, data loss, security breach, user-facing outage - `High` — degraded production service, significant but partial user impact, near-miss in production - `Medium` — staging/non-prod incident, limited user impact, caught before widespread harm - `Low` — developer environment only, debugging session, no use