Agent skill · Code Review & Quality

blameless-postmortem

Google SRE-style blameless postmortem authoring. Structure, timeline construction, contributing-factor extraction, action-item discipline, and the cultural practices that make postmortems produce learning rather than theater. Use when writing a postmortem after an incident, reviewing a draft postmortem, running a postmortem review meeting, building a postmortem template, or teaching a team how to write postmortems that actually improve the system. Complements rca-human-factors (for the "why people did what they did" analysis) and the rca-classical-methods / rca-systems-theoretic / rca-causal-i

majiayu000github.com/majiayu000GitHub ↗
claude-codeMIT
Install
npx skills add majiayu000/claude-skill-registry --skill blameless-postmortem --agent claude-code

Same command for any agent — swap --agent for codex, cursor, copilot.

Facts
Files in the skill folder: 2
SKILL.md size: 16 KB
Bundled scripts: none
Path: skills/analysis/blameless-postmortem/SKILL.md
Open the folder on GitHub →
Where it comes from
Stars: 534
Language: HTML

Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.

From the SKILL.md

# Blameless Postmortems A postmortem is the work product that converts an incident from a surprise into learning. A *blameless* postmortem does this without punishing the people closest to the incident — not because punishment is wrong in principle, but because punishment destroys the reporting culture that makes further learning possible. This skill teaches you how to write one. ## The two purposes of a postmortem 1. **Learning** — teach the organization something it didn't know about itself, so the same incident or its close cousins don't recur. 2. **Accountability** — commit the organization to a specific set of changes with owners and deadlines. These are not competing purposes. They are complementary: learning without accountability is a reading exercise; accountability without learning is theater. A postmortem that fails either purpose is a bad postmortem, regardless of how polished it looks. ## Why "blameless"? Google's SRE book (Beyer et al., 2016, Chapter 15) articulates the principle: *you cannot fix what you cannot see, and people will not show you what they did if they believe they will be punished for it*. Blameless postmortems are a deliberate organizational choice to

What's inside
Steps it walks through
  1. The two purposes of a postmortem
  2. Why "blameless"?
  3. What blameless is not
  4. The Google SRE postmortem template
  5. 1. Title
  6. 2. Status
  7. 3. Summary
  8. 4. Impact
  9. 5. Timeline
  10. 6. Root cause and contributing factors
  11. 7. Resolution
  12. 8. Lessons learned
  13. 9. Action items
  14. Action item discipline
Ships with 1 file
  • metadata.json
More from claude-skill-registry
All skills →
About this skill
What does the blameless-postmortem skill do?

Google SRE-style blameless postmortem authoring. Structure, timeline construction, contributing-factor extraction, action-item discipline, and the cultural practices that make postmortems produce learning rather than theater. Use when writing a postmortem after an incident, reviewing a draft postmortem, running a postmortem review meeting, building a postmortem template, or teaching a team how to write postmortems that actually improve the system. Complements rca-human-factors (for the "why people did what they did" analysis) and the rca-classical-methods / rca-systems-theoretic / rca-causal-i

How do I install it?

Run `npx skills add majiayu000/claude-skill-registry --skill blameless-postmortem --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.

Where does this skill come from?

From majiayu000/claude-skill-registry, a repository with 534 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.

Is a popular skill a good skill?

Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.

Keep going