/game-retrospective

name: game-retrospective
description: >
  Runs a sprint or milestone retrospective in the GDC post-mortem tradition: What Went Right, What
  Went Wrong, seven lenses including AI-assisted development, the Kill List and The One Thing, with
  actions fed into the next sprint. Use for "retro", "sprint retrospective", "milestone review",
  "kill list". Not for a whole-project post-mortem (use game-postmortem).
argument-hint: "[sprint-N or milestone name]"
effort: medium
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(git log *), Bash(git shortlog *)

AlterLab GameForge -- Sprint and Milestone Retrospective

Game development has the best post-mortem tradition in software. Game Developer magazine's long-running Postmortem column (reprinted on Gamasutra) covered games such as *Thief: The Dark Project*, *Baldur's Gate* and *Diablo II* in the same blunt shape: what went right, what went wrong. No spin, no "learnings and opportunities". This workflow brings that format down to the sprint and milestone, where the lessons are still cheap to act on.

It is not an agile ceremony. A corporate retro asks "what could we improve?" A game retro 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 decide whether the game is worth shipping. In 2026 it also asks a third question: **what did the coding agents actually do for us, and what did they cost?** Teams that cannot answer that with numbers end up either over-trusting agents or abandoning them on a hunch.

When to Use / When Not To

Run it when a sprint ends, when a milestone lands (vertical slice, alpha, beta), after a pivot or a big scope cut, when the game is "fine but not fun" and nobody can say why, or when development feels stuck.

| Instead of this skill... | Use | |---|---| | Whole-project or canceled-project post-mortem | `/gameforge:game-postmortem` | | Planning the next sprint from these actions | `/gameforge:game-sprint-plan` | | Project scope has outgrown the schedule | `/gameforge:game-scope-check` | | Analyzing a playtest session itself | `/gameforge:game-playtest` | | Reviewing the design document | `/gameforge:game-design-review` |

Critical Rules

1. **GDC format, not agile format.** "What Went Right / What Went Wrong / Lessons", not "went well / didn't go well". Something either went right or it went wrong. No fence-sitting. 2. **Game-specific lenses.** "Did we communicate well?" is a process question. "Did the core loop deliver the intended experience?" is a game question. This workflow asks the second kind. 3. **The Kill List is mandatory.** The discipline to cut is the discipline to ship. 4. **"The One Thing" is mandatory.** One specific, actionable sentence. If you cannot pick one, you have not thought hard enough. 5. **Evidence over feelings.** "Combat felt off" is not a finding. "Testers disengaged from encounters longer than 45 seconds" is. Back findings with playtest notes, data or incidents. 6. **Read the last retro first.** Were its actions done? A problem that appears twice is not an awareness problem; it is an execution problem, and the action plan changes. 7. **Systems, not people.** "The build broke three times" leads to "there was no pre-merge check", not to a name. 8. **Measure AI use; do not guess it.** Count agent tasks, verify hours and defects traced to agent code from the sprint file and git. Opinions about agents are not findings. 9. **Solo developers do this too.** With no colleagues, this document is the external feedback loop. Write it down; do not just think it.

Step 0: Gather Evidence

Read when present:

• The sprint plan `production/sprints/sprint-NN.md` (goal, tasks, build mode, verify hours) or the

milestone definition in `production/milestones/`.

• The previous retro (`production/sprints/sprint-NN-retro.md` or `production/milestones/*-retro.md`)

and its actions.

• `production/sprints/velocity.md`, `production/session-state/active.md`.
• Playtest notes (`tests/playtest/`, `/gameforge:game-playtest` reports), the bug list or open issues.
• The AI asset provenance log, if the project keeps one.

Run for the period (adjust dates):

git log --since=2026-11-09 --until=2026-11-14 --oneline
git log --since=2026-11-09 --until=2026-11-14 --oneline -i --grep="Co-Authored-By: Claude"
git shortlog -sn --since=2026-11-09 --until=2026-11-14 HEAD
git log --since=2026-11-09 --until=2026-11-14 --oneline -i --grep="revert"

The second command counts commits made with Claude Code's default co-author trailer; adjust the pattern for other agents or if the team turned trailers off. How to trace defects to agent code and fill the AI metrics is in `${CLAUDE_SKILL_DIR}/references/ai-lens.md`; read it before Lens 7.

Then ask **one** AskUserQuestion: scope (**Sprint, about 15 minutes** / Milestone, about 45 minutes); solo or team; and whether playtest data exists for this period. For team retros, facilitation scripts are in `${CLAUDE_SKILL_DIR}/references/facilitation.md`.

The Seven Lenses

Every retro passes through all seven. Not every lens produces findings every time; you still look.

**Lens 1: Core loop validation.** Did the loop deliver the intended experience, and was it fun before content and progression were layered on?

• Strip away content and progression: is the verb set satisfying for 10 minutes in a test room?
• Where does the player feel agency, and where constrained? Are those the right places?
• Did the loop's rhythm drift during implementation? Is one cycle the right length for the session target?
• Reference: *Celeste* began as a four-day PICO-8 jam game (2015); the movement was proven long

before the full game existed. Did you prove your loop before building content on it?

**Lens 2: Pillar integrity.** Did the pillars hold, or drift? Was drift deliberate evolution or unconscious erosion?

• For each pillar, name a decision this pe