postmortem

Overview of postmortem skill

What the postmortem skill does

The postmortem skill is an executive-mentor workflow for turning a failed launch, missed target, bad hire, lost deal, or operational breakdown into a blameless root-cause analysis. It guides the agent through precise event definition, disciplined 5-Whys questioning, and a change register so the output is not just “lessons learned,” but a concrete set of system changes.

Best fit for leadership and Quality Management

This postmortem skill is most useful for founders, executives, operators, product leaders, engineering managers, and Quality Management teams who need to understand why an outcome diverged from plan. It fits situations where the goal is prevention and process improvement, not punishment. For postmortem for Quality Management use cases, the strongest value is translating failures into controls, owners, and measurable follow-up actions.

What makes it different from a generic prompt

A generic “analyze what went wrong” prompt often produces broad commentary. This skill is narrower and more operational: it pushes for a clearly defined event, separates symptoms from causes, discourages scapegoating, and asks what conditions made the failure likely. Its core differentiator is the change register, which helps convert insights into ownership, deadlines, and system-level fixes.

Important adoption notes

The repository path contains a single SKILL.md and no helper scripts, references, or metadata files. That makes postmortem install lightweight, but also means the skill depends heavily on the quality of the context you provide. Use it when you can share enough factual history to support a serious retrospective; avoid it when the event is still politically unsafe, legally sensitive, or based only on rumors.

How to Use postmortem skill

postmortem install and files to inspect

Install from the GitHub skill source with:

npx skills add alirezarezvani/claude-skills --skill postmortem

The source lives at:

c-level-advisor/executive-mentor/skills/postmortem/SKILL.md

Read SKILL.md first because it contains the full operating model. There are no extra rules/, resources/, references/, or scripts/ folders to reconcile, so your main installation decision is whether this single-file workflow matches your retrospective style.

How to call the skill in practice

The skill is designed around the command pattern:

/em:postmortem <event>

A weak invocation is:

/em:postmortem Q3 release slipped

A stronger invocation gives the agent enough material to separate facts, assumptions, and causes:

/em:postmortem The Q3 enterprise release shipped six weeks late. Expected: public launch by Sep 15 with SOC2-ready audit logging. Actual: launch moved to Oct 27, two pilot customers delayed contracts, and support handled 43 escalation tickets. Timeline: scope expanded Aug 8, QA found permission bugs Sep 3, final security review failed Sep 12. Please run a blameless 5-Whys analysis and produce a change register with owners, preventive controls, and follow-up metrics.

Inputs that improve postmortem usage

For best postmortem usage, provide the expected outcome, actual outcome, timeline, first warning signs, impact, key decisions, constraints, and what was known at the time. Include both quantitative evidence and human context: revenue gap, defect count, hiring timeline, missed milestone, customer impact, decision owners, approval bottlenecks, and competing priorities.

Avoid asking the skill to “find who caused this.” Instead, ask it to identify system conditions: unclear ownership, weak escalation paths, unrealistic planning assumptions, missing quality gates, incentive conflicts, or late risk visibility.

Suggested workflow for a useful output

Start with a factual event brief, then ask for the first postmortem draft. Review whether the 5-Whys chain stops too early or jumps to a convenient explanation. Then iterate with evidence: “Pressure-test the root cause against the timeline,” “Separate controllable causes from external shocks,” or “Convert these lessons into a change register suitable for the next exec review.”

The best final artifact usually includes: event definition, impact summary, contributing factors, root causes, non-causes, decisions that looked reasonable at the time, recommended system changes, owners, deadlines, and verification metrics.

postmortem skill FAQ

Is postmortem suitable for beginners?

Yes, if the user can provide a clear event description. The skill’s structure reduces the need to know formal retrospective methods in advance. Beginners should prepare a short timeline and outcome gap before calling it; otherwise, the model may fill missing context with plausible but unverified assumptions.

When should I not use this skill?

Do not use it as a performance review, disciplinary tool, legal investigation, or public incident statement without human review. It is also a poor fit when leadership only wants a polished narrative rather than uncomfortable causal analysis. If the organization cannot act on findings, a postmortem may create frustration instead of improvement.

How is it different from an incident review?

An incident review often focuses on technical service failures and operational recovery. This postmortem skill is broader: missed quarters, failed launches, bad hires, lost deals, product flops, and leadership decisions are all in scope. It can support Quality Management, but it is not a substitute for regulated CAPA, audit, or compliance documentation unless adapted by qualified reviewers.

Does the skill require a specific ecosystem?

No. The skill is plain markdown and can be installed into a compatible skills workflow using the command above. Because there are no scripts or external assets, it is portable across business, product, engineering, and operations contexts. The tradeoff is that it does not automatically ingest dashboards, ticket systems, or incident logs; you must summarize or paste the relevant evidence.

How to Improve postmortem skill

Give the postmortem better raw material

The fastest way to improve postmortem results is to supply a compact evidence pack. Include: goal, actual result, timeline, decision points, missed signals, constraints, stakeholders, impact, and existing hypotheses. Label uncertain claims clearly. For example: “Confirmed: QA blocked release on Sep 12. Hypothesis: sales pressure caused scope expansion. Unknown: whether engineering estimated the new scope.”

Watch for common failure modes

The most common failure is a shallow root cause such as “poor communication” or “lack of ownership.” Ask the agent to go one level deeper: What structure made communication fail? Why was ownership unclear? Why did the planning process allow that ambiguity? Another failure mode is overcorrecting with too many action items. Push for fewer changes that are owned, observable, and likely to prevent recurrence.

Turn findings into a change register

A strong change register should name the change, the root cause it addresses, the owner, due date, success metric, and review cadence. For Quality Management use, add control type, verification method, and evidence required. This makes the skill’s output easier to operationalize in leadership reviews, quarterly planning, release governance, hiring process changes, or continuous improvement programs.

Iterate after the first answer

After the first draft, ask targeted follow-ups: “Which conclusions are evidence-backed versus inferred?”, “What would have prevented this without slowing the team unnecessarily?”, “What early warning metric should we add?”, or “Rewrite the change register for executive accountability.” The postmortem skill works best when treated as a structured investigation partner, not a one-shot report generator.