/game-scope-check

name: "game-scope-check"
description: >
  Evaluate project scope against timeline and resources. Triggers on: "scope creep",
  "feature list", "can we fit this in", "timeline pressure", "resource constraints",
  "cut list", "scope evaluation". Do NOT invoke for sprint planning (use game-sprint-plan)
  or general project status (use game-producer). Part of the AlterLab GameForge collection.
argument-hint: "[feature-list or milestone to evaluate]"
effort: medium
context: fork
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
version: 1.3.0

AlterLab GameForge -- Scope Check Workflow

Scope creep is the number one killer of indie games. Not lack of talent, not bad ideas, not engine limitations. Games die because they grow past the team's capacity to finish them. It happens one "small" addition at a time, each individually reasonable, collectively fatal. The danger is that scope creep feels like progress -- adding a feature feels productive, cutting feels like failure. This workflow exists to invert that psychology: cutting is the skill, and a tight scope is the achievement.

Team Cherry shipped Hollow Knight with 3 people. ConcernedApe shipped Stardew Valley alone. Neither project was small in ambition -- they were ruthlessly disciplined about what to include and what to cut. The games that ship are not the ones with the longest feature lists. They are the ones where every feature earned its place through honest scope accounting.

The core principle: **a finished game with 8 great features beats an abandoned game with 20 half-built ones.** This workflow enforces that principle with concrete tools, not wishful thinking.

Purpose & Triggers

Use this workflow when:

• The feature list has grown since the last scope check
• Someone says "can we fit this in?" or "what if we also added..."
• A milestone deadline is approaching and confidence is low
• The team feels overwhelmed but cannot articulate why
• Sprint velocity is consistently below planned capacity
• Any stakeholder (including yourself) pushes back on cutting features
• The project has never had a formal scope check

Problems this solves:

• Feature lists that only grow, never shrink
• The "just one more thing" pattern that compounds into missed deadlines
• All features labeled "Must Have" because nobody wants to prioritize
• No clear connection between features and available work hours
• Teams afraid to cut features because they lack a framework for deciding what goes
• Scope discussions that devolve into opinion battles instead of data-driven decisions

Critical Rules

1. **One In, One Out.** Adding a feature requires cutting a feature of equivalent effort. No exceptions. No "we'll work harder." No "we'll figure it out." The budget is fixed. Moving a feature from Won't Have to Should Have means moving something from Should Have to Won't Have. Team Cherry cut entire areas from Hollow Knight to ship on time -- and the game is better for it because every surviving area is polished to a mirror shine.

2. **Percentages are law.** MoSCoW allocation must hold: Must Have occupies 60% of total effort, Should Have 25%, Could Have 15%. If Must Have exceeds 60%, the project is at risk regardless of how important each individual feature feels.

3. **Score, don't debate.** The Feature Scoring Matrix replaces opinion with arithmetic. Features are scored on Impact, Feasibility, and Risk. The math decides. If a team member disagrees, they challenge the individual scores, not the outcome.

4. **Buffer is not optional.** A schedule with less than 20% buffer is a schedule that will miss its deadline. Buffer absorbs the unexpected, and in game development, the unexpected is the expected. Treat buffer as sacred -- it is not "extra time for features."

5. **Freeze dates are real.** Feature additions freeze 3 days before any milestone. After the freeze, only bug fixes and polish are permitted. Breaking the freeze requires Producer-level sign-off and a corresponding cut elsewhere.

6. **Honest estimates only.** If you have never built a system like this before, double the estimate. If the tech is unfamiliar, triple it. Optimistic estimates are the fertilizer that scope creep grows in.

Workflow

---

🧠 **PHASE 1: Feature Inventory**

*Goal: Catalog every feature currently planned, in progress, or requested.*

Before you can assess scope, you need a complete picture. This phase produces an exhaustive list. Do not filter yet -- even features you suspect will be cut go on the list.

FEATURE INVENTORY
-------------------------------------------------
ID   | Feature             | Status        | Requestor    | Est. Hours
-------------------------------------------------
F01  | [feature name]      | [planned/     | [who asked]  | [honest
F02  | [feature name]      |  in-progress/ |              |  estimate]
F03  | [feature name]      |  complete/    |              |
...  |                     |  requested]   |              |
-------------------------------------------------

Capture rules:
- Include features already in progress (sunk cost does not protect them)
- Include features someone mentioned casually ("wouldn't it be cool if...")
- Include features assumed but never written down (save system, settings menu)
- Estimate in hours, not days. Hours force specificity.
- If you cannot estimate a feature, mark it [UNKNOWN] -- that is itself a red flag

Ask the user to walk through every planned feature. Probe for hidden features: "Is there a settings menu? A save system? A tutorial? An options screen? Controller support?" These assumed features often consume significant time but never appear on lists.

---

🎯 **PHASE 2: MoSCoW Classification**

*Goal: Sort every feature into four priority tiers with enforced percentages.*

MoSCoW is not a wishlist exercise. It is a resource allocation framework. The percentages are constraints, not guidelines.

MoSCoW CLASSIFICATION
-------------------------------