game-retrospective

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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 period where it changed the outcome. None means it is not operational.
- Name one moment a pillar was compromised and why (schedule, tech limit, a better idea).
- Did an implicit pillar emerge that the team keeps prioritizing? Name it now.

**Lens 3: Scope tier review.** Did Must / Should / Could protect the right work?
- How many Musts shipped, were downgraded, or cut? Would you make each downgrade again?
- Which Should or Could ate more time than planned? Was it worth it?
- Planned vs done hours, and where the gap came from (estimates, verification, interruptions).
- Reference: Jason Schreier's *Blood, Sweat, and Pixels* (2017) describes the years Eric Barone
  spent building *Stardew Valley* alone, with no outside scope authority, and the toll it took.
  Scope discipline is also self-care.

**Lens 4: Flow state analysis.** Where did players enter flow, and where did they bounce?
- Sketch the intended challenge curve for a session; overlay what testers did (retries, long
  sessions, audible reactions vs phone checks, quits).
- Name the flow breakers: menus mid-action, unskippable text, loads at tension peaks.
- Is the difficulty a curve or a cliff? Are the walls intentional gates or friction? Frustration
  is acceptable only when every failure teaches something.

**Lens 5: Technical debt audit.** Which shortcuts are now blocking progress, and which were worth it?
- Top five shortcuts: cost to fix vs cost of not fixing over the next milestone.
- Which debt bought a deadline that mattered (good debt)? Which now causes bugs (bad debt)?
- Does debt cluster in one system? That system needs a redesign, not another patch.
- Bus factor: if the one person who understands the save system leaves, what breaks?

**Lens 6: Ludonarrative check.** Where did mechanics and story reinforce each other, and where did
they contradict?
- Three moments where they aligned; what made them work?
- Any contradiction ("time is running out" while side quests are farmable for hours)?
- What do the mechanics alone say about the game's themes? Is that intended?

From AlterLab-IEU/AlterLab_GameForge, MIT.

More from AlterLab-IEU/AlterLab_GameForge