Incident PostmortemCAUTION

1255 professional Agent Skills for Claude, ChatGPT, Gemini, Cursor & Codex — PRDs, postmortems, leases, medical bills, layoffs, go-bags, new countries. Plain markdown, MIT, in Anthropic's plugin directory. Plus a typed decision layer: which skill, is it safe, ship or slip. Free in-browser or npx pm-

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: incident-postmortem
description: "Write a structured incident postmortem or post-incident review. Use when asked to write a postmortem, incident report, P1/P2 review, outage report, or RCA (root cause analysis). Produces a blameless postmortem with timeline, root cause, contributing factors, impact summary, and action items."
---

# Incident Postmortem Skill

This skill produces a complete, blameless incident postmortem document following industry-standard format. Output enforces blameless framing throughout — system gaps over individual failures — and drives toward specific, closeable action items rather than vague process commitments.

> **Not quite this?** Use `agent-incident-postmortem` when an AI agent caused the incident (runaway tool use, a shipped hallucination).

## Proposes Actions

The action items don't have to stay on the page: hand them to [`action-runner`](../action-runner/SKILL.md), which previews them (dry-run, risk-rated), runs only what you approve via the connected action MCP, and records what was done back to the brain. Typical: **file a follow-up issue per action item** (🟡), assigned to its owner with a due date. This skill proposes; action-runner gates and runs — never silently.

## Where this sits — turning an incident into fixes

Third in the incident-response spine: **`/slo-error-budget` (frame) →
`/debugging-log-analyser` → `incident-postmortem` → `/oncall-runbook`**. It receives the
**root-cause diagnosis** from `/debugging-log-analyser` (read it rather than
re-diagnosing) and hands `/oncall-runbook` **the contributing factors and prioritised
action items** — and the error budget from `/slo-error-budget` decides how urgent those
actions are. *Blameless*, *root cause vs contributing factors*, and *action item* are
defined once in [`docs/craft/incident-response.md`](../../docs/craft/incident-response.md);
blameless is the load-bearing rule.

## The loop

A postmortem fails the moment it assigns blame — the honest data dries up and every
future incident is under-reported. Phase 1 sets that frame; everything depends on it.

1. **Establish blameless framing first.** State up front that this examines the *system*
   that let a competent person make the move, never the person. This isn't politeness —
   it's the precondition for the truthful timeline the rest of the skill needs.
   **Done when:** the framing is explicit and no sentence in the document blames an
   individual; failures are attributed to system gaps.
2. **Build the timeline from evidence.** Reconstruct start → detection → mitigation →
   resolution with real timestamps (from the diagnosis and logs, not memory). Detection,
   mitigation, and resolution are distinct events — track each.
   **Done when:** the timeline has real timestamps and separates detection/mitigation/
   resolution, and the impact is quantified (users, duration, scope).
3. **Find the root cause AND the contributing factors.** The root cause is one thing;
   the contributing factors are what let it reach users and persist (the missing alert,
   the skipped canary, the unclear runbook). A postmortem with a root cause and no
   contributing factors hasn't looked hard enough.
   **Done when:** at least the load-bearing contributing factors are named, each pointing
   at a system gap that's fixable.
4. **Drive to owned, dated action items — governed by the budget.** Convert factors into
   specific action items, each with an owner and a date; vague "improve monitoring"
   items decay. Prioritise them against the error budget (spent → now; healthy → soon).
   **Done when:** every action item has an owner and a date, and `/oncall-runbook` could
   turn the detection/mitigation learnings into an entry without re-analysing the incident.

## Required Inputs

Work from what is given. If any of these is missing, still produce the complete output: fill each gap with a reasonable assumption marked *(assumed, confirm)* and list those assumptions at the end. Ask a question first only when the core subject itself is missing (there is nothing to write about).
- **Incident title / ID**
- **Severity** (P1 / P2 / P3 or SEV1 / SEV2 / SEV3)
- **Date and duration** of the incident
- **What happened** (rough notes are fine — the skill will structure them)
- **Services or systems affected**
- **Customer impact** (how many users, what was degraded)
- **How it was detected**
- **How it was resolved**
- **Initial thoughts on root cause**
- **Action items already identified** (optional)
- **Responders** (who was on-call or responded — names or roles; used for the timeline, not for blame)
- **Customer or external communications sent** (optional — any status page updates, emails, or support messages with timestamps)

## Reads from / Writes to the Brain

If a [`professional-brain`](../professional-brain/SKILL.md) (`brain/`) exists, use it before asking:

- **Read first:** the affected system's `entities/` file and any related prior `decisions/` or past incidents (recurring root causes are the most important thing to surface).
- **Write after:** log the action items and decisions to `decisions/`, and the root-cause learning to `knowledge/` — tag a measured cause `[data]` and a suspected one `[hunch]`, never the reverse.

## Deeper Materials

- **`references/root-cause-digging.md`** — five-whys done properly (stop at a changeable system property, branch into cause/detection/response chains), a contributing-factor taxonomy to sweep, and blame-shaped → systemic language rewrites. Use it while writing the Root Cause section and to reframe any blameful input notes.
- **`templates/review-meeting-agenda.md`** — a 45-minute, document-first agenda for the postmortem review meeting, with ground rules and an action-item quality gate. Offer it alongside the finished postmortem.

## Output Format

---

# Incident Postmortem: [Incident Title]

**Incident ID:** [ID]
**Severity:** [P1/P2/P3]
**Date:** [Date]
**Duration:** [Start time → Resolution time — total duration]
**S

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

templates/pm-discovery-agent/skills/assumption-mapper/SKILL.md

templates/pm-discovery-agent/skills/discovery-interview-guide/SKILL.md

templates/pm-discovery-agent/skills/job-story-mapper/SKILL.md

templates/pm-discovery-agent/skills/user-interview-synthesis/SKILL.md

templates/pm-launch-agent/skills/content-calendar/SKILL.md

Gates applied: no_behavioural_pass.