game-postmortem

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.

---

From AlterLab-IEU/AlterLab_GameForge, MIT.

More from AlterLab-IEU/AlterLab_GameForge