Postmortem

When something breaks in production or a project goes sideways, you need a structured way to figure out what happened without it turning into a blame session. This walks you through running a proper postmortem, helping you document the timeline, identify root causes, and extract actionable lessons. It's the kind of thing that separates teams that repeat mistakes from ones that actually learn. The framework keeps discussions productive and ensures you capture insights while they're fresh. Best used right after an incident when everyone's still around and the details haven't gotten fuzzy.

skills.sh installs: 1.5K
GitHub stars: 29.5K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add alirezarezvani/claude-skills --skill postmortem --agent claude-code

Installs into .claude/skills of the current project.

Files

/executive-mentor:postmortem — Honest Analysis of What Went Wrong

Command: /executive-mentor:postmortem <event>

Not blame. Understanding. The failed deal, the missed quarter, the feature that flopped, the hire that didn't work out. What actually happened, why, and what changes as a result.

Why Most Post-Mortems Fail

They become one of two things:

The blame session — someone gets scapegoated, defensive walls go up, actual causes don't get examined, and the same problem happens again in a different form.

The whitewash — "We learned a lot, we're going to do better, here are 12 vague action items." Nothing changes. Same problem, different quarter.

A real post-mortem is neither. It's a rigorous investigation into a system failure. Not "whose fault was it" but "what conditions made this outcome predictable in hindsight?"

The purpose: extract the maximum learning value from a failure so you can prevent recurrence and improve the system.