What problem does it solve?
After an outage, teams struggle to produce postmortems that are blameless, evidence-based, and actionable — timelines get reconstructed from memory, triggers get mistaken for root causes, and action items ship without owners or dates. This Skill enforces a disciplined Google SRE-style postmortem process so every incident produces a durable document that actually prevents recurrence.
Core Features & Use Cases
- Blamelessness enforcement: Names systems and roles instead of individuals, reframes blame-seeking requests, and treats every human action as reasonable given the information available at the time.
- Evidence-sourced timelines: Requires every timeline entry to cite an artifact (alert ID, deploy log, dashboard, chat timestamp), explicitly labels recollection-based entries, and surfaces the detection gap between onset and first page.
- Repeat-class detection: Scans prior postmortems in
postmortems/ for the same subsystem and elevates recurrences into the Summary, since a repeat means a prior action item failed to land.
- Verifiable action items: Requires an owner, due date, and checkable done-condition per item, classified as prevention, mitigation, or detection, with runbook stubs auto-created in
guides/ for guide-shaped items.
- Use Case: After a 47-minute checkout outage caused by a config change that halved the connection pool, ask the agent to write the postmortem — it pulls deploy logs and chat transcripts, builds a sourced timeline, separates trigger from root cause, links the two prior pool-exhaustion incidents, and files owned action items including a new runbook stub.
Quick Start
Ask your agent to write a blameless postmortem for the incident that happened on a given date, describing the affected system and what was observed.
