/game-postmortem

name: game-postmortem
description: >
  Runs a data-driven post-mortem for a shipped, canceled or major-phase project: git history, sprint
  and retro records, scope and quality trends, and what AI agents contributed and cost per
  milestone, ending in owned lessons archived to production/milestones/. Use for "post-mortem",
  "project review", "what did we learn". Not for a single sprint (use game-retrospective).
argument-hint: "[project, or milestone name such as alpha]"
effort: high
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(git log *), Bash(git rev-list *), Bash(git shortlog *), Bash(git tag *), Bash(gh issue list *), Bash(sort *), Bash(uniq *), Bash(head *)

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?"

| Instead of this skill... | Use | |---|---| | A single sprint or milestone retro | `/gameforge:game-retrospective` | | Reviewing the design document | `/gameforge:game-design-review` | | Live-game metrics and KPIs after launch | `/gameforge:game-analytics-setup` | | Starting the next project with these lessons | `/gameforge:game-start` |

Critical Rules

1. **No blame, only patterns.** Attribute problems to processes, decisions and conditions, never to people. "The rendering pipeline had no review gate" is actionable. "Dave wrote bad shaders" is toxic and useless. The same applies to tools: "the agent broke it" is not a root cause. 2. **Data before feelings.** Collect the quantitative record (commits, velocity, scope, bugs, AI use) before reflection. Numbers anchor the conversation and prevent revisionist memory. 3. **Equal weight to successes and failures.** Analyzing only failures breeds helplessness; only successes, blind spots. 4. **Concrete over abstract.** "Communicate better" is not a lesson. "Hold a 15-minute art/code sync at the start of each sprint" is. Every lesson produces an action with an owner and a check. 5. **AI use is measured per milestone.** Agent share, review cost, defects traced to agent code and vibe debt come from records, not from impressions. 6. **Archive it where the next project will find it.** `production/milestones/` and a pointer in the project's `CLAUDE.md` or design index. A post-mortem nobody rereads has zero value. 7. **If you publish, be consistent.** A public post-mortem's statements about AI use must match the game's store disclosures and credits.

Phase 0: Scope and Setup

Ask **one** AskUserQuestion (defaults in bold): 1. Scope -- **whole project** / a phase or milestone (name it) / canceled project. 2. Audience -- **internal only** / team blog / public post-mortem or talk. 3. Team or solo (decides whether Phase 2 is a group session or self-reflection).

Define the period's start and end (first commit or phase start; tag, release date or cancellation). Use tags as milestone boundaries where they exist.

Phase 1: Data Collection

Run the commands below for the period, then read the project records. Command recipes for cadence, crunch detection, churn and per-milestone agent share, with how to interpret each, are in `${CLAUDE_SKILL_DIR}/references/data-collection.md`; read it before running Phase 1.

git rev-list --count HEAD
git log --reverse --format="%ad %h %s" --date=short | head -1
git log -1 --format="%ad %h %s" --date=short
git tag -l --sort=creatordate --format="%(refname:short) %(creatordate:short)"
git shortlog -sn --no-merges HEAD
git log --format= --name-only | sort | uniq -c | sort -rn | head -20
git rev-list --count -i --grep="Co-Authored-By: Claude" <tagA>..<tagB>
gh issue list --state closed --limit 200

Read when present:

• Every sprint plan and retro in `production/sprints/`, and `production/sprints/velocity.md`.
• Milestone definitions and milestone retros in `production/milestones/`.
• `design/gdd.md` (original vs current version via its change log), `design/pillars.md`,

`design/systems-index.md`.

• Playtest reports, the bug tracker, store reviews and analytics if shipped.
• The AI asset provenance log and the store AI disclosure text, if any.
• `production/session-state/active.md` and decisions recorded there.

Quantitative picture to assemble:

• Duration (planned vs actual), commit cadence (crunch periods, dead zones), contributors.
• Churn hotspots (most-changed files are c