post-mortem

Overview of post-mortem skill

What the post-mortem skill does

The post-mortem skill is a strategic retrospective workflow for reviewing an executed decision against the success metrics, kill criteria, and dissent captured before the decision was made. It is not a generic “lessons learned” prompt. Its main job is to close a strategic planning loop by forcing the review to compare planned assumptions with actual outcomes.

Best fit for Strategic Planning reviews

This post-mortem skill fits founders, executives, chiefs of staff, product leaders, and strategy operators who already run decisions through a structured cadence. It is especially useful when a pricing change, market entry, hiring plan, product bet, or cost-cutting decision reaches a 90-day checkpoint, triggers a kill criterion, or needs quarterly review.

Why it is different from a normal retrospective

The differentiator is pre-commitment. The skill asks for the decision record, execution plan, and actual outcomes, then scores the result against criteria written before execution. That reduces hindsight bias, prevents teams from redefining success after the fact, and preserves dissent as evidence rather than treating it as political noise.

What to know before install

The repository path is c-level-advisor/c-level-agents/skills/post-mortem, and the skill is contained in SKILL.md with no extra scripts, references, or helper resources. That makes the post-mortem install lightweight, but it also means output quality depends heavily on the records you provide. If you do not have original assumptions, thresholds, or execution notes, the skill can still help, but the review will be less rigorous.

How to Use post-mortem skill

post-mortem install and first file to read

Install from the GitHub skill repository with:

npx skills add alirezarezvani/claude-skills --skill post-mortem

After installation, read SKILL.md first. It defines the command shape, when to run it, required inputs, and the expected saved output path: ~/.claude/postmortems/YYYY-MM-DD-<slug>.md. There are no separate rules/, resources/, or scripts/ folders to inspect for this skill, so the main decision is whether your team can supply enough input evidence.

Inputs the post-mortem skill needs

For strong post-mortem usage, prepare three input groups:

• Decision record: original decision title, date, owner, options rejected, assumptions, success criteria, kill criteria, and dissent.
• Execution plan: milestones, responsible teams, planned interventions, timing, and constraints.
• Actual outcomes: metrics, incidents, customer signals, revenue/cost impact, timeline deviations, and qualitative evidence.

Weak input: “Review our pricing change.”

Stronger input: “Run /cs:post-mortem on the Q2 pricing change. Decision date: 2026-04-03. Success criterion: net revenue retention above 108% by day 90; kill criterion: logo churn above 6% in SMB. Dissent: sales warned annual contracts would stall. Actuals: NRR 104%, SMB logo churn 7.2%, enterprise expansion up 11%, sales cycle length +18 days.”

A practical post-mortem workflow

Use the skill when a decision reaches a review event, not whenever a discussion feels unresolved. Good triggers include the 90-day checkpoint, a kill criterion firing, a major reversal, or the quarterly review of strategic bets.

A practical flow:

1. Gather the original /cs:decide output or equivalent decision memo.
2. Attach the /cs:execute plan or the closest project plan.
3. Add actual metrics and notable events without interpreting them yet.
4. Ask the skill to score status as WIN, PARTIAL, LOSS, or MIXED.
5. Request explicit comparison against pre-committed criteria and preserved dissent.
6. Save the result to your postmortem archive for future planning calibration.

Prompt pattern for better results

A useful prompt should name the decision path, the review trigger, and the evidence standard:

/cs:post-mortem <decision-path>

Then add context such as:

“Use only the criteria that existed before execution. Do not invent new success measures. If evidence is missing, mark it as unknown. Separate outcome scoring, assumption audit, dissent review, decision-quality lessons, and follow-up actions.”

This matters because the post-mortem skill is designed for strategic accountability. If you ask it to “make sense of what happened,” it may produce a softer narrative. If you ask it to score against named thresholds, it produces a more useful management artifact.

post-mortem skill FAQ

Is the post-mortem skill only for executives?

No. The path and command are part of a C-level advisor workflow, but the underlying pattern works for any team making consequential decisions. Product managers, operations leads, startup founders, and strategy teams can use it if they document decisions before execution.

How is it better than asking for a retrospective?

A normal retrospective often focuses on team feelings, process gaps, and broad lessons. This post-mortem guide centers on decision quality: were the assumptions right, did success criteria hold, did kill criteria trigger, and did dissent predict the failure mode? That makes it more useful for Strategic Planning and portfolio review.

When should I not use this skill?

Do not use it as the first step for an unmade decision, a brainstorming session, or a project with no measurable intended outcome. Use /cs:post-mortem after execution has produced evidence. If you need to choose between options, use a decision or boardroom-style workflow first, then return to post-mortem later.

Is it beginner-friendly?

Yes, but only if beginners understand that the skill needs evidence. It will not magically reconstruct the original decision record. New users should start with one completed decision, provide the original goal and actual outcomes, and let the skill identify missing criteria so future decisions are documented better.

How to Improve post-mortem skill

Improve the post-mortem by preserving the original evidence

The biggest quality lever is preserving the original decision artifacts. Keep success thresholds, kill criteria, expected risks, and dissent in a stable decision record before execution begins. The post-mortem skill becomes much more valuable when it can compare actual outcomes to a pre-existing baseline rather than to memory.

Avoid common failure modes

Common failures include vague metrics, retrofitted success definitions, missing dissent, and over-indexing on one headline result. A pricing decision might improve revenue while damaging retention; a hiring plan might fill roles while slowing delivery. Ask the skill to label mixed outcomes instead of forcing a clean win/loss story.

Strengthen prompts with metrics and context

Better prompts include dates, thresholds, owners, decision scope, business context, and raw outcomes. Instead of saying “The launch underperformed,” provide “Activation target was 35%; actual was 26%; paid conversion improved from 4.1% to 5.0%; support tickets doubled for onboarding.” The skill can then separate assumption errors from execution errors.

Iterate after the first output

After the first post-mortem, ask follow-up questions that improve strategic learning:

• “Which assumption was most wrong?”
• “Which dissenting concern should become a future decision checklist item?”
• “Were the kill criteria too late, too strict, or ignored?”
• “What should change in our next /cs:decide record?”

This turns the post-mortem from a one-time report into a feedback loop for better strategic planning.