/game-sprint-plan

name: game-sprint-plan
description: >
  Builds a sprint plan for a team or solo developer: one pillar-aligned goal, day-sized tasks that
  each end in a check, dependencies, capacity with buffer, AI-agent estimates with review budgets
  and vibe-debt paydown, written to production/sprints/. Not for whole-project scope (use
  game-scope-check).
argument-hint: "[sprint number, milestone, or focus area]"
effort: high
disable-model-invocation: true
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(git log *), Bash(git status *), Bash(git branch *), Bash(gh issue list *)

AlterLab GameForge -- Sprint Planning

Game sprints fail for different reasons than software sprints. A business-app team struggles with unclear requirements; a game team struggles with cross-discipline dependencies and the unpredictability of fun. You can build an inventory system exactly to spec and discover in the playtest that it makes the game worse. So a game sprint plans discovery time (spikes, feel passes, playtests) as real work, not as leftovers.

There is a newer failure mode. With Claude Code or a similar agent, code arrives fast, and it is easy to plan a sprint as if generation were the whole job. It is not. Someone still has to run the checks, read the diff, play the change and notice what the agent added that nobody asked for. This workflow budgets that verification on every task, and reserves capacity to pay down the "vibe debt" that accumulates when agent-written code is accepted faster than it is understood.

The output is a sprint plan file in `production/sprints/` that a team, a solo developer, or a coding agent working from task cards can execute against.

When to Use / When Not To

Use before a new sprint, when a solo developer wants to structure the next one or two weeks, right after a retrospective, when a milestone needs decomposing, or when design work from `game-gdd-author` or `game-design-review` must become executable tasks.

| Instead of this skill... | Use | |---|---| | Is the whole project too big for the date? | `/gameforge:game-scope-check` | | Reviewing how the last sprint went | `/gameforge:game-retrospective` | | Milestone dates, risk and publisher-facing schedule | `/gameforge:game-producer` | | Moment-to-moment agent build loop for one task | `/gameforge:game-vibe-code` | | Coordinating several studio roles on one problem | `/gameforge:game-team-orchestrator` | | A 48-72 hour jam schedule | `/gameforge:game-jam-mode` |

Critical Rules

1. **One goal per sprint.** A single sentence that defines success, framed as a player or project outcome ("testers can finish one full run"), not a feature list. Ship everything but miss the goal and the sprint failed. 2. **Tasks are at most one day and end in a check.** More than 8 hours of human time means decompose further. Every task names how "done" is decided: acceptance check IDs from the GDD, a test command and its expected result, or a playtest observation. 3. **Every agent-built task carries a verify budget.** Estimate build time and verify time separately. A task whose verification was skipped is not done, whatever the agent reported. 4. **Buffer after estimating.** Subtract 20% of capacity for teams and 30% for solo developers (rules of thumb) for meetings, build breaks, hardware, and "I'll just refactor this one thing". 5. **Dependencies are first-class.** A blocked task is not ready. Map chains, find the critical path, schedule blockers first. 6. **Scope tiers flex the sprint.** Must / Should / Could / Won't. Cutting a Could on Wednesday is healthy; cutting a Must on Friday is a crisis. 7. **Velocity honesty.** Plan from measured completion in `production/sprints/velocity.md`, not from hope. If agents doubled your commits but not your completed Musts, your velocity did not double. 8. **Pay down vibe debt every sprint.** A fixed slot, sized from the last retrospective, not whatever is left over. 9. **Trace the goal to a pillar.** Infrastructure sprints are fine; call them out. A goal that serves no pillar and no infrastructure need is drift; flag it.

Step 0: Gather Context

Run these (a failure just means "no data"; note it and continue):

git log --oneline -20
git status --short
git branch --list
gh issue list --limit 15 --state open

Read when present:

• `.gameforge/project.json` -- phase, engine, pillars.
• `production/session-state/active.md` -- current focus, decisions, blockers.
• The latest `production/sprints/sprint-NN.md` and `production/sprints/sprint-NN-retro.md` --

carry-over, retro actions, the AI lens findings (vibe debt, review cost).

• `production/sprints/velocity.md` -- planned vs completed history.
• `design/gdd.md` §13 (acceptance criteria) and §17 (milestones); `design/systems-index.md`.
• `production/milestones/` -- the current milestone's definition of done.

Then ask **one** AskUserQuestion with up to four questions, offering defaults: 1. Sprint length -- **1 week** (solo default) or 2 weeks (team default). 2. Who is available, and for how many days (note PTO, part-time, contractors). 3. How will most work be built -- by hand, **agent-assisted** (a human drives, the agent drafts), or agent-led (the agent implements from task cards, the human verifies). 4. Which milestone this sprint serves, if `production/milestones/` does not make it obvious.

If velocity data is missing, say this sprint establishes the baseline and plan conservatively.

Step 1: Sprint Goal

Format: "By the end of this sprint, [deliverable] is [state] so that [value]."

GOOD: "By the end of this sprint, the core combat loop is playable with 3 enemy types so that
       we can run the first combat playtest on Friday."
GOOD: "By the end of this sprint, save/load round-trips all current game state so that
       playtesters can resume sessions."
BAD:  "Work on combat stuff."            (not evaluable)
BAD:  "Fix bugs and add features."       (two goals)

Serves pil