FREESKILL v1.0UPDATED 2026-08

Post Mortems

A project post-mortem preserves what worked, separates what failed from what was missing, and turns the evidence into owned changes for the next project.

Retrospectives often flatten facts, opinions, disagreement, and vague intentions into a list called lessons learned. The list sounds reasonable and changes nothing.

This playbook reconstructs the intended outcome and actual result, inventories the perspectives supplied, and uses three questions to preserve success as carefully as failure. Each lesson becomes a continue, change, or start action with ownership, timing, and proof.

A lesson without an owner, due date, and adoption evidence is only an observation.

SIGNALS YOU NEED THIS

The review records failures but cannot say what should continue.

A person is presented as the lesson instead of an action or decision.

The action plan says communicate better without defining a practice.

REPLACES

Blame retrospectives, forced consensus, and lesson lists with no follow-through.

PAIRS WITH

Correction of Errors, Done, Standard Operating Procedures, and Successful Meetings.

0 of 4 steps complete

STEP 01Set the project and evidence boundary

Name the project, period, intended outcome, customer or user benefit, business purpose, scope, and actual result. State which records and perspectives are missing.

PROJECT
  Knowledge-base migration
  Goal: move 42 published articles by July 31 without breaking old links
  Result: 42 moved by July 29
  Missing perspectives: Evidence needed

STEP 02Use the three questions

Sort evidence into What worked, What did not work, and What was missing. Preserve disagreement and keep a repeated opinion labeled as opinion.

WHAT WORKED
  Review checks caught seven bad links before launch.

WHAT DID NOT WORK
  Role assignments changed twice.

WHAT WAS MISSING
  Support handoff before launch.

STEP 03Build themes without forcing consensus

Connect observations only when evidence supports the shared issue. Keep blame claims, disputes, and unknown results visible instead of turning them into team conclusions.

THEME
  Role stability
  Evidence: two recorded assignment changes
  Consequence: Evidence needed
  Disagreement: none supplied

UNSUPPORTED CLAIM
  One contributor caused every delay. Timeline evidence needed.

STEP 04Convert lessons into owned future decisions

Give every continue, change, or start action a specific practice, scope, owner, due date, and success evidence. Do not prescribe one method to every project.

START
  Complete the support handoff before launch.
  Applies to: migrations with support-facing changes
  Owner: Owner needed
  Due: Date needed
  Proof: handoff receipt recorded before launch

Download the folder into your agent's skills directory. It uses only the material you provide and makes no remote calls.

skills/post-mortems

post-mortems/
├── SKILL.md                         ← draft and audit modes
├── meta.yaml                        ← version, sources, test prompts, changelog
├── LICENSE.md                       ← MIT
├── assets/
│   ├── post-mortem-template.md      ← three-question project review
│   └── post-mortem-audit-scorecard.md ← evidence and action audit
└── references/
    └── three-question-synthesis.md  ← category and theme rules

INVOKE IT LIKE THIS

"Write the post mortem for this launch."

Download skill v1.0 View source files

WORKS WITHClaude Code