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 document is stored in production/milestones/ or design/postmortems/ and referenced in future project setup. A post-mortem that sits in a folder and is never read again has zero value.

Workflow

The post-mortem runs in five phases. Each phase has specific inputs, activities, and outputs. The phases build on each other -- do not skip phases or reorder them.

Phase 1: Data Collection

Gather quantitative and qualitative data about the project or milestone period.

Quantitative data (from auto-populated fields and manual collection):

• Total development time (first commit to release/milestone)
• Commit frequency patterns (were there crunch periods? Dead zones?)
• File churn analysis (which files changed most? These are complexity hotspots)
• Bug trajectory (did bug count trend up or down over time?)
• Sprint velocity history (if available from production/session-state/velocity.json)
• Scope changes (features added after initial plan, features cut)

Qualitative data (collected from team or solo dev reflection):

• What was the original vision? How does the shipped product compare?
• What were the stated design pillars? Were they followed?
• What decisions felt right at the time but proved wrong later?
• What external factors affected development (market shifts, personal, tooling)?
• What was the team's morale trajectory across the project?

For solo developers, qualitative data comes from self-reflection. The developer should review their own commit messages, TODO comments, and any personal development logs.

Phase 2: Team Reflection

Structured reflection using specific, answerable questions. These questions are designed to extract signal from noise.

What went well (preserve and amplify):

1. What single decision had the most positive impact on the project?
2. What tool, process, or practice would you definitely use again?
3. What was the best collaboration moment between disciplines?
4. What feature shipped closer to the original vision than expected? Why?
5. What risk did the team identify early and mitigate successfully?

What went wrong (understand and fix):

1. What single decision caused the most rework or wasted time?
2. What problem was visible early but addressed too late?
3. Where did communication break down between disciplines or team members?
4. What feature drifted furthest from the original design? What caused the drift?
5. What technical debt was accumulated deliberately? Was the tradeoff worth it?

What was surprising (learn from the unexpected):

1. What task took dramatically longer (or shorter) than estimated? Why?
2. What player/tester feedback was