game-postmortem

AlterLab GameForge -- Project Post-Mortem

Every shipped game has a story behind it that is worth more to the next project than the game itself. The post-mortem is where that story is extracted, structured and turned into reusable knowledge. Without one, the team repeats the same mistakes on the next project, not because it is incompetent but because memory is selective and unstructured reflection drifts toward narratives instead of patterns. The GDC Vault and decades of Game Developer magazine postmortems exist because studios learned this the hard way.

A good post-mortem is not a blame session and not a victory lap. It is a structured data extraction: facts first, then reflection, then patterns, then a small number of lessons that each change something concrete.

Projects built with coding agents add a question earlier post-mortems never had to answer: what did the agents actually contribute, and what did they cost? This workflow answers it per milestone, with numbers, so the next project can decide where agents belong.

Relationship to game-retrospective

game-retrospective handles sprints and milestones: short cycles, immediate actions for the next sprint. The post-mortem covers a whole project or a major phase and looks for systemic patterns across those cycles. It ingests every retro it can find.

• "What should we do differently next sprint?" -> /gameforge:game-retrospective
• "What should we do differently next project (or next phase)?" -> this skill

When to Use / When Not To

Use after a launch, a cancellation, a major milestone (vertical slice, alpha, beta, 1.0), before starting a new project (to retrieve and apply the last post-mortem), or when a new team member asks "what went wrong last time?"