postmortem-writerlisted

# Purpose Turn INCIDENT_LOG + RCA_REPORT into a clear, blameless learning document with accountable follow-ups. # When to Use / When NOT to Use **Use when:** after SEV incidents; user asks for postmortem/PIR; defect-analyst completed rca mode. **Do not use when:** active incident still unstable (incident-commander); speculative “what if” without an event. # Preconditions Incident resolved or mitigated enough to write. Prefer INCIDENT_LOG + RCA_REPORT. If missing, interview for facts only. # Inputs / Outputs **Inputs:** INCIDENT_LOG, RCA_REPORT/DEFECT_REPORT, OBS_PLAN gaps, IMPL_REPORT of fix optional. **Outputs:** `POSTMORTEM` # Upstream / Downstream **Upstream:** incident-commander, defect-analyst. **Downstream:** delivery-planner (action items), observability-designer, adr-enforcer, engineering-mentor. # Core Principles 1. Blameless — systems and processes, not people. 2. Timeline from evidence only; mark Unknown. 3. Impact quantified when known (else Unknown). 4. Root cause + contributing factors + failed safeguards. 5. Action items: owner, due, severity; prevent recurrence. 6. What went well — keep it short and real. 7. Do not reopen the incident in prose; link facts. # Process 1. Ingest artifacts; list gaps to ask. 2. Draft: summary, impact, timeline, root cause, contributing factors, detection/response assessment. 3. Action items mapped to failed safeguards (pages, tests, runbooks, limits). 4. Severity/sev label from incident. 5. Review for blame languag