/game-retrospective

name: "game-retrospective"
description: >
  Run a game development post-mortem rooted in the GDC tradition. Triggers on:
  "retrospective", "retro", "post-mortem", "lessons learned", "what went right", "what
  went wrong", "kill list review". Do NOT invoke for design document review (use
  game-design-review) or playtesting (use game-playtest). Part of the AlterLab GameForge
  collection.
argument-hint: "[sprint-N or milestone-name or 'project']"
effort: medium
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
version: 1.3.0

AlterLab GameForge -- Game Development Post-Mortem

The game industry has the best post-mortem tradition in software. Gamasutra's classic post-mortem series — Diablo II, Baldur's Gate, Black & White, Thief — taught an entire generation of developers more than any textbook because they were brutally honest. Five things that went right. Five things that went wrong. No spin, no corporate sanitizing, no "learnings and opportunities." Just the truth about what happened when a team tried to ship a game.

This workflow follows that tradition. Not Scrum retrospectives. Not agile ceremonies. Game development post-mortems — the format that Supergiant used to iterate Hades from a decent roguelike into a genre-defining masterpiece, that ConcernedApe used to survive five years of solo development on Stardew Valley without losing his mind, that the Dwarf Fortress brothers used to sustain a twenty-year development cycle without burning out or losing direction.

The difference between a corporate retro and a game post-mortem: a corporate retro asks "what could we improve?" A game post-mortem asks "did we build the right game, and did we build it the right way?" One optimizes process. The other interrogates the creative and technical decisions that determine whether your game ships, and whether it is worth shipping.

Purpose & Triggers

Run this workflow when:

• A sprint ends and the next one has not started
• A milestone lands (vertical slice, alpha, beta, gold)
• A project ships or is cancelled
• Development feels stuck and nobody can articulate why
• The game is "fine but not fun" and the team needs to diagnose the gap
• A major pivot or scope cut just happened and the dust has settled
• Before starting a new project, to extract lessons from the last one

Problems this solves:

• Repeating the same design mistakes because nobody documented why a feature failed
• Cutting the wrong features because scope pressure overrides design judgment
• Technical debt accumulating invisibly until it blocks progress
• Teams that playtest but never analyze the patterns in playtest data
• Solo developers who skip reflection and wonder why their third prototype dies the

same death as the first two

• The "it felt off but we shipped it anyway" regret cycle

Critical Rules

1. **GDC format, not agile format.** The structure is "What Went Right / What Went Wrong / Lessons Learned." Not "went well / didn't go well / action items." The distinction matters: GDC format forces you to commit to a judgment. Something either went right or it went wrong. Fence-sitting is not allowed.

2. **Game-specific lenses, not generic process questions.** Every retrospective passes through six game development lenses (detailed below). "Did we communicate well?" is a process question. "Did the core loop deliver the intended experience?" is a game development question. This workflow asks the second kind.

3. **The Kill List is mandatory.** Every retrospective includes a review of what was cut. The discipline to cut is the discipline to ship. The Kill List forces you to evaluate whether your cuts were correct, premature, or too late.

4. **"The One Thing" is mandatory.** After all analysis, distill everything to a single sentence. One lesson. The one that changes how you work next time. If you cannot pick one, you have not thought hard enough.

5. **Evidence over feelings.** "The combat felt off" is not a finding. "Playtesters disengaged during combat encounters longer than 45 seconds, suggesting the damage loop is too slow for the encounter scale" is a finding. Back everything with data, playtest observations, or specific incidents.

6. **Read the last post-mortem first.** Before starting, review the previous retrospective. Did those lessons actually change anything? If the same problems appear twice, the issue is not awareness — it is execution. That distinction changes the action plan entirely.

7. **Solo devs do this too.** ConcernedApe developed Stardew Valley alone for five years. He has spoken publicly about the burnout, the scope creep, the periods where he almost quit. Solo developers have zero external feedback loops. This workflow IS your external feedback loop. Write it down. Do not just think about it.

The Six Game Development Lenses

These lenses replace generic retro questions. Every retrospective — sprint, milestone, or project — passes through all six. Not every lens will produce findings every time. That is fine. But you must look through each one.

---

**Lens 1: Core Loop Validation**

Did the core loop deliver the intended experience? Was it fun in isolation before content, narrative, and progression systems were layered on top?

Celeste's core loop — dash, jump, climb — was fun in a blank room with white rectangles. Madeline's movement felt good before a single strawberry, B-side, or story beat existed. If your core loop is not fun in a blank room, content will not save it. This is the most important lens because everything else is built on top of it.

Questions to answer:

• Strip away all content, progression, and narrative. Is the core verb set satisfying on

its own? Can you play the loop for 10 minutes in a test room and want to keep going?

• Where in the loop does the player feel agency? Where do they feel constrained? Are those

the right places?

• What is the loop's rhythm? Is it the rhythm you designed, or did i