agentsclimarketplace

Incident postmortem

Skill Amey-Thakur/AI-SKILLS/skills/devops/incident-postmortem

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill incident-postmortem

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

2 things to look at

  • 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 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

Write a blameless postmortem that finds systemic causes and produces actions that actually prevent recurrence. Use after an outage, data incident, or serious bug reaches users.

SKILL.md

2.4 KB, as published. Nobody here has run it

Incident postmortem

The purpose is a system that cannot fail this way again: not a culprit. The moment a postmortem blames a person, everyone stops telling the truth in the next one.

Structure

  1. Summary: three sentences: what broke, who felt it and for how long, and the one-line cause. Written last, placed first.
  2. Impact: numbers, not adjectives: users affected, requests failed, data lost or at risk, duration, money if known. "Significant impact" is a tell that nobody measured.
  3. Timeline: timestamped facts from first trigger to full resolution: what happened, what people saw, what they did. Include the wrong turns; the 40 minutes spent on the wrong hypothesis is signal about your observability, not a person's failure.
  4. Root cause analysis: walk the why-chain past the trigger to the conditions: the deploy was the spark; the missing rate limit, the silent fallback, and the alert that pages nobody are the fuel. Most incidents need three to five "why"s before reaching a cause you can fix in a system. Name mechanisms ("retries amplified load 40×"), never persons ("X pushed bad config" → "config validation accepted a value that cannot work in production").
  5. What went well / what was lucky: the alert that fired correctly; the fact it happened Tuesday 10:00 and not Saturday 03:00. Luck listed honestly today is a to-do item, not a defense, tomorrow.
  6. Action items: each with an owner, a date, and a mechanism: prevention (make the failure impossible), detection (find it in one minute, not forty), mitigation (halve the blast radius). "Be more careful" is not an action item; "reject configs that fail validation at deploy time" is. Three completed actions beat twelve open ones.

Rules

  • Facts and interpretation stay visibly separate; the timeline is facts only.
  • Write for the engineer who joins next year: no unexpanded acronyms, no tribal context assumed.
  • If the same class of incident has happened before, say so and link it , a repeat is a statement about the previous action items.

Litmus test

If every person involved left the company tomorrow, does the document still prevent the next occurrence?

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.