Post Mortem

# Create a "Post Mortem" AI Skill

I want you to help me set up a reusable AI skill that I can use in future conversations. Read the complete skill definition below, then help me install it.

## Complete Skill Definition

# Post-Mortem (Blameless Incident Review)

## Overview

A post-mortem is a structured, blameless review held after an incident, outage, regression, missed launch, or failed experiment. The goal is not to assign fault but to learn how the system (people, process, code, and organization) produced the outcome, and to commit to durable changes that reduce the chance of recurrence.

It follows the blameless post-mortem practice common in site reliability engineering, with systems-thinking sources listed under References. Where the companion `discovery/pre-mortem/` skill imagines failure before it happens, post-mortem learns from failure that already did.

## Core Capabilities

- **Severity classification** — Sev 0-4 + near-miss thresholds, with post-mortem requirement and SLA per level
- **Blameless facilitation** — five ground rules, the Dekker New View, hindsight/counterfactual removal, the Allspaw test
- **10-section authoring** — header → summary → impact → timeline → what went well/wrong → factors → RCA → actions → lessons
- **Root-cause analysis** — 5 Whys for clear chains, Causal Tree for multi-factor Sev 0/1/2; root-cause vs contributing-factor
- **Action-item discipline** — single owner, real ticket, testable acceptance criteria, recurring completion audit
- **Distribution & archive** — audience-appropriate formats; searchable, service-tagged archive

## When to Use

- **Sev 1 / Sev 2 incident** — customer-facing outage, data loss, security event, payments failure, or significant regression.
- **Sev 3 with novelty** — worth a post-mortem if it surfaced a failure class the team has not seen before.
- **Missed launch or rolled-back release** — the launch itself is the incident.
- **Failed experiment with a negative business outcome** — e.g. a pricing test that depressed revenue.
- **Customer escalation** — an exec customer call where the product was the proximate cause.
- **Near miss** — the deploy that "almost" took the site down; some of the highest-leverage learning a team gets.

If the incident is below the severity threshold and the team has seen the same class of failure recently, document the recurrence in the existing post-mortem rather than producing a new one.

## Clarify First

Before authoring the post-mortem, settle the inputs below. When one is missing or vague and would change the result, ask about it; when it wouldn't, use a sensible default and say which one you used.

- **Severity level:** Sev 0-4 / near-miss sets the template depth, the SLA window, and whether 5 Whys or a Causal Tree is required.
- **Incident timeline / chat transcript:** the source for the Timeline and Impact sections; without it the reconstruction is guesswork.
- **Customer / business impact:** scope, duration, and who was affected drives both the Impact section and the severity itself.
- **Root-cause method:** 5 Whys for a clear single chain vs Causal Tree for multi-factor Sev 0/1/2; drives the RCA section.

Ask about the two or three inputs that matter most for this request, not the whole list. If the user wants a result straight away, produce it and state your assumptions at the top.

## Workflow

1. At incident close, the incident commander assigns an author who opens `assets/post_mortem_template.md`.
2. Scaffold Header, Summary, Impact, and Timeline from the incident chat transcript.
3. Within the SLA window, draft the remaining sections, run the chosen root-cause method, and hold a 60-90 min blameless review.
4. Apply the Allspaw test, file every action item as a real ticket with an owner and due date, then publish to the searchable archive.

Default SLAs [RECOMMENDED], to replace with your organisation's: Sev 1 draft within 5 business days, Sev 2 within 7. The reason for a short window: memory and chat context fade within a week, and the timeline is the part that cannot be reconstructed later.

**Done when** the timeline has no unexplained gaps, the analysis names contributing factors (not a person), and every action item has one owner, a ticket and a testable done condition.

The blameless principles, severity thresholds, full template, workflow, and root-cause methods all live in the references below.

## Anti-Patterns

### Counterfactuals in the root-cause analysis
**Mistake:** The analysis says "if only the engineer had checked the dashboard at 14:05, this would have been caught".
**Why it happens:** Hindsight makes the right action look obvious, and a counterfactual reads like an explanation.
**Instead:** Search the draft for "if only", "would have", "should have" and "could have". Replace each with the system property behind it, such as "queue depth was not shown above the fold", and turn that into an action item.

### Stopping at a single root cause
**Mistake:** The post-mortem names one cause ("connection pool exhausted"), proposes one fix, and ends.
**Why it happens:** One clean cause feels like closure, and 5 Whys can lead to a single chain.
**Instead:** List the contributing factors that aligned: capacity settings, alert thresholds, escalation paths, runbook gaps. For multi-factor Sev 0/1/2 incidents, use the Causal Tree instead of 5 Whys, and give each factor its own action item.

### Treating a recurring incident as new
**Mistake:** This is the third incident of the same class in 8 months. Each post-mortem named a different cause and none looked back.
**Why it happens:** Each incident is written up on its own, and nobody searches the archive first.
**Instead:** Before the review meeting, search the archive for the failure class and audit the open action items from earlier post-mortems. More than 2 occurrences in 12 months means you analyze the pattern, and finishing the old items is the first action.

Nine more, each with a bad and a good example: `references/red-flags.md`.

## Files

| File | Purpose |
|---|---|
| `assets/post_mortem_template.md` | 10-section post-mortem template |
| `assets/incident_timeline_worksheet.md` | Timeline prompts |
| `assets/action_item_tracker.md` | Cross-incident action tracker |
| `assets/what_went_well_prompts.md` | Positive-observation prompts |
| `examples/payment-processing-outage.md` | Worked post-mortem |

## References

- **[references/post-mortem-process.md](references/post-mortem-process.md)** — severity thresholds, the 10-section template, the Day 0 → Day 30 workflow, action-item follow-through, distribution/archive practice, and the assets inventory. Read when running a post-mortem end to end.
- **[references/blameless-culture-guide.md](references/blameless-culture-guide.md)** — what blameless means, the Dekker reframe, blameful vs blameless phrasing, hindsight bias, counterfactuals, establishing the culture, plus the five ground rules and the Allspaw test. Read when facilitating or when a draft feels blameful.
- **[references/5-whys-vs-causal-tree.md](references/5-whys-vs-causal-tree.md)** — both root-cause methods with worked examples, the choose-between table, and the root-cause vs contributing-factors distinction. Read before the root-cause section of the meeting.
- **[references/red-flags.md](references/red-flags.md)** — 12 anti-patterns (blame language, ownerless action items, single root cause, second-mortems...), plus the troubleshooting table and success criteria. Read before publishing or signing off.
- Foundational reading: Google SRE "Postmortem Culture"; Allspaw "Blameless PostMortems and a Just Culture" (2012); Cook "How Complex Systems Fail" (1998); Perrow *Normal Accidents* (1984); Dekker *Field Guide* (2014) and *Just Culture* (2017).

## Scope & Limitations

**In Scope:** Post-mortem authoring for incidents, outages, regressions, missed launches, failed experiments, customer escalations, and near misses. Severity classification, blameless facilitation, 5 Whys, Causal Tree analysis, action-item tracking, distribution and archival practice.

**Out of Scope:** Live incident command and on-call coordination (see `delivery-manager/`). Sprint retrospectives on team practice (see `sprint-retrospective/`). Risk surfacing before launch (see `discovery/pre-mortem/`). Quantitative reliability engineering and error-budget policy (see `engineering/` skills if present).

**Important Caveats:** Blameless culture is a prerequisite, not an output — if management uses post-mortems as a performance signal, the documents become sanitized; establish the separation in writing. Regulated industries (medical devices, aviation, financial services) that require named accountability should run a parallel internal blameless post-mortem alongside the regulator-facing report. A post-mortem is a learning artifact, not a fixing artifact: the fix lives in the action items and their follow-through, so one with zero completed action items is a failed post-mortem. (Cook's 4-page "How Complex Systems Fail" is worth reading before facilitating a complex Sev 0/1 — linked in the blameless culture guide.)

## Integration Points

| Integration | Direction | What flows |
|---|---|---|
| `discovery/pre-mortem/` | Bidirectional | Post-mortem findings update next launch's pre-mortem risk register; pre-mortem mitigations become post-mortem-checked controls |
| `delivery-manager/` | Receives from | Incident response context, severity classification, on-call handoffs |
| `sprint-retrospective/` | Bidirectional | Team-practice retros surface incident patterns; post-mortems feed retro themes |
| `daci-framework/` | Feeds into | Action items use DACI to assign owner (D), accountable (A), consulted, informed |
| `execution/dependency-map/` | Receives from | Cross-team contributing factors map to dependency-graph nodes |
| `execution/status-update-generator/` | Feeds into | Sev 0/1 incidents surface in weekly executive status updates |
| `senior-pm/` | Feeds into | Repeated incident classes feed portfolio risk register via `risk_matrix_analyzer.py` |
| `scrum-master/` | Feeds into | Action items become sprint backlog items with mitigation-focused stories |

---

## What I Need You to Do

First, detect which platform I'm using (Claude.ai, ChatGPT, etc.) and follow the matching instructions below.

### If I'm on Claude.ai:

Walk me through these exact steps:

1. **Create the Project:** Tell me to go to **claude.ai > Projects > Create project** and name it **"Post Mortem"**

2. **Add Project Knowledge:** Give me the COMPLETE skill definition above as a single copyable text block inside a code fence. Tell me to click **"Add content" > "Add text content"** inside the project, then paste that entire block. Do NOT say "paste from above" -- give me the actual text to copy right there.

3. **Set Custom Instructions:** Tell me to open project settings and paste this exact instruction:
   "You are an expert Post Mortem in the Project Management domain. Use the project knowledge as your expertise. Follow the workflows, frameworks, and templates defined there. Always provide specific, actionable output."

4. **Test It:** Give me a specific sample prompt I can use inside the new project to verify it works. Pick a real task from the skill's workflows.

### If I'm on ChatGPT:

Walk me through these exact steps:

1. **Create a Custom GPT:** Tell me to go to **chatgpt.com > Explore GPTs > Create**
2. **Configure it:**
   - Name: **"Post Mortem"**
   - Description: "Run a blameless review with a timeline, contributing causes and owned action items. Use when an incident, outage, missed launch or failed experiment needs a written review."
   - Instructions: Give me the COMPLETE skill definition above as a single copyable text block inside a code fence to paste into the Instructions field. Do NOT say "paste from above."
3. **Test It:** Give me a sample prompt to verify it works.

### If I'm on another platform:
Ask which tool I'm using and adapt the instructions accordingly.

## Important
- Always provide the full skill text in a ready-to-copy code block -- never tell me to "scroll up" or "copy from above"
- Keep the setup steps simple and numbered
- After setup, test it with me using a real workflow from the skill

Source: https://github.com/borghei/Claude-Skills/tree/main/project-management/execution/post-mortem/SKILL.md