/game-sprint-plan

name: "game-sprint-plan"
description: >
  Invoke when the user needs to plan a development sprint, break down tasks, schedule
  game work, or organize a sprint with cross-discipline dependencies. Triggers on:
  "sprint plan", "task breakdown", "development planning", "scheduling", "sprint
  backlog". Do NOT invoke for scope evaluation (use game-scope-check) or retrospectives
  (use game-retrospective). Part of the AlterLab GameForge collection.
argument-hint: "[milestone or focus area]"
model: opus
effort: high
disable-model-invocation: true
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
version: 1.3.0

AlterLab GameForge -- Sprint Planning Workflow

Game development sprints fail for different reasons than software sprints. A SaaS team struggles with unclear requirements and shifting priorities. A game team struggles with cross-discipline dependencies and the fundamental unpredictability of "fun." You can spec out an inventory system perfectly, build it to spec, and discover in playtest that it makes the game worse. Supergiant's sprint model (documented in their GDC talks) accounts for this by reserving explicit "discovery time" in every sprint -- time allocated to test whether what they built actually feels good, not just whether it works.

Sprint planning for games must build in structured discovery time, explicit scope tiers that flex without chaos, and a dependency model that respects the sequential nature of art-to-integration pipelines. This workflow produces a concrete sprint plan document a team can execute against.

Purpose & Triggers

Use this workflow when:

• A team is about to start a new development sprint
• A solo developer wants to structure their next 1-2 weeks of work
• After a sprint retrospective, when planning the next iteration
• When a milestone is approaching and work needs to be decomposed
• The user finished `game-brainstorm` or `game-design-review` and needs to turn

design decisions into executable tasks

Problems this solves:

• Sprints with vague goals that cannot be evaluated as done or not done
• Tasks estimated at "a few days" that actually take two weeks
• Art and code tasks planned in parallel when art must finish first
• Teams that commit to more work than their capacity allows every sprint
• Risks that were obvious in retrospect but invisible in planning
• No velocity tracking, so every sprint's estimates are guesses
• Scope creep disguised as small additions that accumulate into missed deadlines

Critical Rules

1. **One goal per sprint.** The sprint goal is a single sentence that defines success. If the sprint achieves this goal and nothing else, it was a successful sprint. If the sprint ships everything on the task list but misses the goal, it failed. Hades' sprint goals during Early Access were experience-focused: "players feel the narrative progressing even when they die." That clarity prevents the "we did a lot of stuff but nothing feels finished" anti-pattern.

2. **Tasks max 1 day.** Any task estimated at more than 1 day must be decomposed further. Large tasks hide complexity and create false confidence in estimates. If a task seems irreducible at more than 1 day, it is either too vague or the developer does not yet understand the work well enough (which is itself a discovery task). Dead Cells' development at Motion Twin used day-sized tasks for everything -- even major features like new biomes were decomposed into dozens of single-day tasks with clear done criteria.

3. **The 20% buffer is non-negotiable.** After calculating raw capacity, subtract 20%. This covers meetings, code reviews, unexpected bugs, build issues, hardware problems, and the general friction of collaborative work. Teams that skip the buffer consistently overcommit and consistently underdeliver. Solo devs are not exempt; context switching, research tangents, and "I'll just refactor this one thing" all eat time.

4. **Dependencies are first-class concerns.** A task that is blocked by another task is not ready to be worked. Map dependencies explicitly, identify the critical path, and ensure blocking tasks are scheduled first. The most common game-dev dependency chain: design spec --> art/audio asset creation --> code integration --> QA verification.

5. **Scope tiers enable flexibility.** Not everything in a sprint has equal priority. Use Must/Should/Could/Won't tiers so the team knows what to cut first when reality intrudes. Cutting a Could-Have on Wednesday is healthy scope management. Cutting a Must-Have on Friday is a crisis.

6. **Velocity honesty over velocity aspirations.** If the team has completed an average of 30 story points in each of the last 3 sprints, planning 45 points this sprint is not ambition -- it is delusion. Use actual historical velocity, not hoped-for velocity. Larian's milestone-based development for BG3 worked because they tracked velocity obsessively and adjusted scope accordingly -- not because they crunched harder.

7. **Align with pillars.** Every sprint goal traces to a design pillar. If a sprint goal does not serve any pillar, the team is either working on infrastructure (acceptable but call it out) or drifting from the vision (flag for discussion). Supergiant's sprint goals are always framed as player experience statements, not feature lists -- "players feel the weight of their weapon choices" not "implement weapon system." Reference `docs/game-design-theory.md` for pillar methodology and `docs/collaboration-protocol.md` for cross-discipline coordination rules.

Sprint Context (Auto-populated)

These values are injected automatically via shell preprocessing before the skill content reaches Claude. They provide real-time project data so sprint planning starts from the actual state of the codebase, not from memory or assumption.

• Recent commits: !`git log --oneline -20 2>/dev/null || echo "No git history"`
• Open issues: !`gh issue list --limit 10 --state open 2>/dev/null || echo "No