Incident postmortem

Skill sandev/engineering-os/skills/operating-and-reliability/incident-postmortem

An operating system for engineering: durable, opinionated playbooks (Agent Skills) for software architecture, AI/agentic systems, product engineering, and technical leadership. Read by humans, loaded by any LLM/agent.

Install

npx -y skills add sandev/engineering-os --skill incident-postmortem

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Run a production incident and write a blameless postmortem that finds systemic causes and durable action items. Use when there is an active outage or degradation, or when the user needs to write or review a postmortem, RCA, or incident retrospective.

SKILL.md

4.6 KB, as published. Nobody here has run it

Incident Response & Postmortem

Two jobs: stop the bleeding during the incident, then learn without blame afterward. The measure of a healthy engineering org is not zero incidents, it is how much it learns from each one.

Part 1, During the incident

Priority order is fixed: mitigate first, diagnose second. Restoring service beats understanding root cause in the moment.

Severity (set one from customer impact, not cause)

SEV1: critical: major outage or data loss, broad customer impact. All-hands, leadership notified immediately.
SEV2: significant: partial outage or serious degradation; urgent but contained.
SEV3: minor: limited or cosmetic impact; handle in normal hours.

When unsure, over-declare, you can always downgrade. Severity drives the response, not blame.

Roles (assign explicitly, even for a team of two)

Incident Commander (IC): owns decisions and coordination. Not the person with hands on keyboard.
Ops/hands-on: investigates and applies fixes.
Communications: updates stakeholders and status page on a cadence.

Flow

- [ ] Declare the incident; assign IC. Set a severity.
- [ ] Open a single coordination channel; all activity goes there.
- [ ] Assess impact: who/what is affected, since when, how badly.
- [ ] Mitigate: roll back, fail over, disable the feature, scale up, buy stability.
- [ ] Communicate on a fixed cadence, even with "no change yet."
- [ ] Once stable, confirm recovery with data, then stand down.
- [ ] Preserve evidence (logs, dashboards, timeline) for the postmortem.

Good telemetry is what makes detection fast and root cause findable, see the observability-and-slos skill; for the diagnosis itself, see the debugging skill.

Principles

Mitigate with the fastest safe lever (usually rollback) before hunting root cause.
One source of truth for status; avoid parallel side-conversations.
Change one thing at a time and observe; panic-changing multiple variables hides what worked.
Over-communicate. Silence during an outage erodes trust faster than bad news.

Part 2, The postmortem (blameless)

Write one for every significant incident, within a few days while memory is fresh.

Blameless means

Focus on systems and conditions, not individuals. "An engineer ran the migration" → "the deploy tooling allowed an unreviewed migration to reach production with no dry-run gate." People act reasonably given the information and tools they had; if a human error caused an outage, the system that let that error reach production is the finding. Blame kills the honesty that makes postmortems useful.

Template

# Postmortem: <incident title>

- Date / duration: ...
- Severity & impact: users affected, requests failed, revenue/SLA impact.
- Authors: ...   Status: Draft | Reviewed

## Summary
A few sentences: what broke, the impact, and how it was resolved.

## Timeline (UTC)
- HH:MM, trigger / first symptom
- HH:MM, detected (how? alert or human?)
- HH:MM, key actions and what they did
- HH:MM, mitigated
- HH:MM, fully resolved

## Impact
Quantified: duration, users, requests, data, money.

## Root cause analysis
The chain of contributing causes. Ask "why" until you reach systemic
factors, not a person. Usually several causes combine, capture all.

## What went well / what was hard
Detection, response, tooling, communication, honestly.

## Action items
| Action | Type (prevent/detect/mitigate) | Owner | Due |
|--------|-------------------------------|-------|-----|
Each item is specific, owned, dated, and tracked to completion.

Quality bar

Root cause reaches a systemic factor (process, tooling, design gap), not "human made a mistake."
Detection is examined: did we find it, or did a customer? How fast?
Action items are concrete, owned, dated, and tracked: a postmortem whose actions are never done is theater.
Prefer actions that prevent the class of failure, not just this one instance.
Tone stays blameless throughout.

Anti-patterns

Naming and shaming; "root cause: human error."
Action items with no owner or date (they never happen).
Diagnosing root cause while the site is still down.
Skipping the postmortem because "we know what happened."
Only fixing the exact bug, ignoring the class of failure and the detection gap.

Gives 0 of the 12 instructions most incident response skills give

Counted across 224 of the 224 authors here whose files we hold, read 2026-08-06

Conduct a blameless postmortem within 48 hoursin 24 of 224, across 14 files
perform root cause analysis using five whysin 24 of 224, across 20 files
write a blameless postmortemin 22 of 224, across 19 files
Update stakeholders every 15 to 30 minutesin 19 of 224, across 9 files
assign an owner and due date to every action itemin 18 of 224
Classify incident severity within 5 minutesin 17 of 224, across 7 files
Create a post-mortem documentin 17 of 224, across 14 files
Assign all action items with deadlinesin 14 of 224, across 6 files
Implement immediate mitigation prioritizing user restorationin 13 of 224, across 3 files
assign one incident commanderin 12 of 224
Stop and ask for clarification if inputs are missingin 10 of 224, across 2 files
Escalate earlyin 10 of 224, across 2 files

Said here and by no other author read

mitigate service impact before diagnosing root cause
set severity from customer impact
open a single coordination channel for all activity
focus analysis on systems and conditions over individuals
reach systemic factors during root cause analysis
examine how the incident was detected

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.