/game-postmortem

name: "game-postmortem"
description: >
  Run a structured post-mortem analyzing what went well, what went wrong, and extractable
  lessons. Pulls git history, milestone data, and retrospective notes automatically.
  Triggers on: "post-mortem", "project review", "what did we learn", "lessons learned",
  or when a major milestone or project is complete. Do NOT invoke for sprint-level
  retrospectives (use game-retrospective) or design reviews (use game-design-review).
  Part of the AlterLab GameForge collection.
argument-hint: "[milestone-name or 'project']"
effort: medium
allowed-tools: Read, Glob, Grep, Edit, Write, Bash
version: 1.3.0

AlterLab GameForge -- Post-Mortem Analysis Workflow

Every shipped game has a story behind it that is more valuable than the game itself. The post-mortem is where that story gets extracted, structured, and turned into reusable knowledge. Without a post-mortem, the team repeats the same mistakes on the next project -- not because they are incompetent, but because memory is selective and unstructured reflection gravitates toward narratives rather than patterns.

The GDC Vault is filled with post-mortems from studios that learned this the hard way. Supergiant documented every Hades development cycle with structured retrospectives, and that institutional knowledge directly informed the Hades II production pipeline. Obsidian's post-mortem on Fallout: New Vegas identified the "18-month death march" anti-pattern that they deliberately avoided in The Outer Worlds' production. ConcernedApe's Stardew Valley post-mortem revealed that the solo dev's biggest risk was not technical -- it was the absence of external feedback loops for 3.5 years.

A good post-mortem is not a blame session. It is not a victory lap. It is a structured data extraction process that produces actionable knowledge for the next project, the next sprint, or the next team.

Purpose and Triggers

Use this workflow when:

• A project ships and the team wants to capture what they learned
• A major milestone completes (vertical slice, alpha, beta, launch)
• A sprint cycle ends and the team wants deeper analysis than a retrospective provides
• A project is cancelled and the team needs to extract salvageable lessons
• A new team member asks "what went wrong last time?"

Problems this solves:

• Repeating the same production mistakes across projects
• Survivorship bias where only successes get remembered
• Blame-oriented culture where failures are hidden rather than analyzed
• Lost institutional knowledge when team members leave
• Vague "lessons learned" lists that are too abstract to act on

Relationship to game-retrospective

The `game-retrospective` skill handles sprint-level and milestone-level reflections -- shorter, more focused, with immediate actionable outputs for the next sprint. The post-mortem is broader and deeper: it analyzes the entire project or a major phase, looking for systemic patterns rather than sprint-specific issues.

Use `game-retrospective` for: "What should we do differently next sprint?" Use `game-postmortem` for: "What should we do differently next project?"

If retrospective data exists from previous sprints, the post-mortem ingests it as input data for pattern analysis (see Phase 3).

Project Data (Auto-populated)

These values are injected automatically via shell preprocessing. They provide quantitative project data that grounds the post-mortem in facts rather than feelings.

• Total commits: !`git rev-list --count HEAD 2>/dev/null || echo "No git history"`
• Project duration: !`echo "First commit: $(git log --reverse --format='%ai' 2>/dev/null | head -1 || echo 'unknown') / Latest commit: $(git log -1 --format='%ai' 2>/dev/null || echo 'unknown')"`
• Commit frequency (last 12 weeks): !`git log --since="12 weeks ago" --format="%aW" 2>/dev/null | sort | uniq -c | sort -rn | head -12 || echo "No recent history"`
• Contributors: !`git shortlog -sn --no-merges 2>/dev/null || echo "No contributor data"`
• File churn (most changed files): !`git log --pretty=format: --name-only 2>/dev/null | sort | uniq -c | sort -rn | head -15 || echo "No file history"`
• Tag/milestone history: !`git tag -l --sort=-creatordate --format='%(refname:short) %(creatordate:short)' 2>/dev/null | head -10 || echo "No tags"`
• Open issues: !`gh issue list --limit 20 --state open 2>/dev/null || echo "No GitHub issues accessible"`
• Closed issues: !`gh issue list --limit 20 --state closed 2>/dev/null || echo "No GitHub issues accessible"`
• Retrospective notes: !`ls production/sprints/*retro* production/sprints/*retrospective* 2>/dev/null || echo "No retrospective files found"`
• Sprint data: !`ls production/session-state/last-sprint.json production/session-state/velocity.json 2>/dev/null || echo "No sprint state data"`

Critical Rules

1. **No blame, only patterns.** A post-mortem that names individuals as the cause of failures is a post-mortem that will never be honest. Attribute problems to processes, decisions, and systemic conditions -- never to people. "The rendering pipeline had no code review gate" is actionable. "Dave wrote bad shaders" is toxic and useless.

2. **Data before feelings.** Start with the quantitative data (commit history, velocity trends, bug counts) before moving to subjective reflection. Numbers anchor the conversation and prevent revisionist memory. The auto-populated data above is the starting point, not decoration.

3. **Equal weight to successes and failures.** Teams that only analyze failures develop learned helplessness. Teams that only celebrate successes develop blind spots. The post-mortem allocates structured time to both.

4. **Concrete over abstract.** "We should communicate better" is not a lesson. "We should hold a 15-minute sync at the start of each sprint to align art and code priorities" is a lesson. Every finding must produce a specific, implementable action item.

5. **Archive the output.** The post-mortem do