/game-scope-check

name: game-scope-check
description: >
  Checks scope against time and capacity: feature inventory, MoSCoW with effort caps, impact and
  risk scores, buffer math, scope-creep signals and a cut list, with velocity calibrated for
  AI-agent work and vibe debt counted as risk. Use for "scope creep", "can we fit this", "what
  should we cut", "are we on track". Not for sprint task planning (use game-sprint-plan).
argument-hint: "[feature list, milestone or deadline to evaluate]"
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(git log *), Bash(git shortlog *), Bash(git diff --stat *)
effort: medium

AlterLab GameForge -- Scope Check

Games rarely die from one bad decision. They die from a feature list that grows one reasonable addition at a time until it no longer fits the team that has to finish it. Adding feels like progress and cutting feels like failure; this workflow inverts that. Cutting is the skill, and a tight scope is the achievement. **A finished game with eight polished features beats an abandoned one with twenty half-built ones.**

AI coding agents change the arithmetic but not the principle. They make the first playable and the boilerplate dramatically cheaper, which makes it easy to add features. They do not make integration, content, QA, polish or review proportionally cheaper, and unreviewed agent code creates debt that comes due later. The 2026 Vibe Jam gold winner, built with Claude Code in about two weeks (roughly 27k lines, 188+ commits, per Wccftech's July 2026 report on its workflow), was scoped to 5-10 minutes of play, and its creator built the 3D map by hand. Scope to what the whole pipeline can finish, not to how fast the prototype appeared.

Purpose & Triggers

**Use this workflow when:**

• The feature list has grown since the last check, or nobody has ever done one.
• Someone says "can we fit this in?" or "it'd only take the agent an hour."
• A milestone, demo, festival or launch date is approaching and confidence is low.
• Sprint velocity keeps missing plan, or agent sessions keep re-fixing the same systems.
• The team feels overwhelmed and cannot say why.

**Do NOT use this workflow when:**

| Need | Route to | |---|---| | Turning the agreed scope into sprint tasks | `game-sprint-plan` | | Making the final ship-date or scope call, risk register, milestones | `game-producer` (this check feeds its decision) | | De-risking one unknown feature before estimating it | `game-prototype` | | Scoping a 48-72 hour jam | `game-jam-mode` | | Assessing code health and refactor needs in detail | `game-code-review`, `game-technical-director` | | Reviewing the design itself | `game-design-review` | | Looking back at why scope slipped | `game-retrospective`, `game-postmortem` |

Inputs I Read First

• `.gameforge/project.json` (phase, pillars), feature lists and the GDD in `design/`, sprint plans

in `production/sprints/`, milestones in `production/milestones/`, previous checks in `production/scope/`, and `production/session-state/active.md`.

• **Git history as velocity evidence** (read-only): `git log --since="8 weeks ago" --oneline`,

`git shortlog -sn --since="8 weeks ago"`, `git diff --stat <last-milestone-tag>..HEAD`, and the share of commits with agent co-author trailers. Real throughput beats remembered throughput.

• Ask up to three AskUserQuestion items, with defaults:

1. **Deadline and what it is**: demo or festival, early access, 1.0 launch, publisher milestone. 2. **Capacity**: people x honest hours per week (default: one person, 15 h/week, part-time). 3. **How the code gets written**: mostly by agents, mixed (default), mostly by hand.

Critical Rules

1. **One in, one out.** Adding a feature means cutting one of equal effort. No "we'll work harder." 2. **Effort caps.** Must Haves take no more than 60% of estimated effort, with about 20% in Could Haves as contingency (the DSDM/Agile Business Consortium MoSCoW guidance); Should Haves fill the rest. If Must Haves exceed 60%, the plan is at risk however important each feature feels. 3. **Score, don't debate.** Disagreements challenge individual scores, not the outcome. 4. **Buffer is not optional.** Below 20% buffer, expect to miss the date (rule of thumb). Buffer is for surprises, never for features. 5. **Freeze dates are real.** No new features in the final days before a milestone (default three working days; a week before a festival or store submission). 6. **Estimate the whole feature.** Design + code + content + integration + QA + polish + review. Agents speed up some of these and not others; estimate each part separately. 7. **Velocity comes from evidence.** Plan from measured throughput on finished work, not from how fast a prototype appeared. 8. **Vibe debt is scope.** Agent-written code nobody has reviewed, tested or understood is work that has not been done yet. Put its stabilization cost in the plan. 9. **Write the cut list before you need it.** Decide what goes first while everyone is calm.

Workflow

**PHASE 1: Feature Inventory**

Catalog everything planned, in progress, requested or assumed. Do not filter yet.

FEATURE INVENTORY
ID   | Feature                 | Status       | Requested by | Pillar served
F01  | Grapple traversal       | in progress  | design       | "fluid movement"
F02  | Online co-op            | requested    | Discord      | --
F03  | Settings + rebinding    | assumed      | --           | (table stakes)

Probe for the hidden features that never make lists but always take time: settings, rebinding, save/load and save migration, controller support, pause and quit flows, basic accessibility options, localization hooks, tutorial or onboarding, credits, crash reporting, store page assets and trailer, demo build, platform builds (Steam Deck, web, mobile), achievements, AI-use disclosure and the asset provenance log, analytics consent. Read `${CLAUDE_SKILL_DIR}/references/cut-list-playbook.md` for the full hidden-