Use when an outage, production incident, or significant service degradation has occurred and the team needs to write a structured blameless post-mortem. Triggers on phrases like "write a post-mortem", "incident review", "what went wrong", "outage report", "root cause analysis", or "RCA". Covers timeline reconstruction, contributing factor analysis, impact quantification, and action item generation with owners.
SkillScore91Maintained
Automatic
◆DevOps & SRE pack
Last verified 8/2/2026
What it changes
Passed 21 of 23 test cases with the skill, and 16 of 23 without it.
Without skill70%
With skill91%
Checks it passed that the model alone missed
States that the summary should be 2 to 3 sentences long.
Explains that a post-mortem is not required for minor bugs caught in staging.
Includes action description, owner, due date, and priority in the table columns.
and 2 more in the full report
5 fixed16 passed either way2 still failing0 broke
Pass-rate lift
+22 pp
Tokens
+51%
Agent turns
0%
Response time
-40%
Model gemini-3.6-flashMeasured 8/2/2026v121 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
We are building the action items section for our post-incident writeup. What specific column headers must be present in the markdown action items table?
What was checked, without and with the skill
Checked
Without skill
With skill
Includes action description, owner, due date, and priority in the table columns.
Missed
Passed
case-16 · gemini-3.6-flash · 8/2/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md199 linessingle file
Incident Post-Mortem
Guide a team through writing a structured, blameless post-mortem after a production incident. The output is a document that builds shared understanding, identifies root causes without blame, and produces concrete action items to prevent recurrence.
Blameless Principle
Systems fail, not people. The goal is to understand HOW the incident happened — not WHO caused it. Avoid language like "X forgot to", "Y should have known". Use "the system did not", "the process lacked", "the alert did not fire".
When to Use
Production outage or service degradation has been resolved
A significant near-miss occurred (would have been an incident if caught later)
User-facing errors, data loss, or SLA breach happened
Team wants to capture learnings before context fades
Not for: Minor bugs caught in staging, planned maintenance windows, or incidents with no learning value.
Input Requirements
Gather these details before writing the post-mortem. Ask for anything missing:
Incident Metadata
Incident title (short, descriptive)
Date and time of detection (with timezone)
Date and time of resolution
Severity / impact level (P1–P4 or equivalent)
Incident commander / on-call owner
Impact
Affected services and systems
User-facing impact (errors, slowness, full outage)
Write effective blameless postmortems with root cause analysis, timelines, and action items. Use when conducting incident reviews, writing postmortem documents, or improving incident response processes.