用途：评估游戏项目范围与时间线、资源是否匹配，防止功能列表无限膨胀导致项目烂尾。触发场景包括：功能列表比上次检查变长、有人问“能不能塞进去”、里程碑临近信心不足、迭代速度持续低于计划、有人反对砍功能、项目从未做过正式范围检查。
主要能力（按工作流阶段）：一、功能清单：把所有已计划、进行中、被口头提到的功能逐条登记，按小时估算，含设置菜单、存档、教程等隐性功能。二、MoSCoW 分类：Must Have 占 60% 工作量、Should Have 25%、Could Have 15%，Won't Have 明确延后；Must Have 超 60% 或 Won't Have 为空即为红旗。三、功能评分矩阵：按 影响 1-5、可行性 1-5、风险 1-5，用 Score=(影响×可行性)/风险 计算；≥3.0 保留，2.0-3.0 评估，<2.0 砍掉。四、时间线测算：净产能=人数×每周工时×剩余周数，扣 15% 管理开销，再减去剩余工作量得缓冲比例；≥30% 健康，20-30% 注意，10-20% 警告，<10% 危急，负值即超载。五、范围蔓延检测：10 项信号清单按命中数分级。六、变更冻结：里程碑前 3 天冻结新功能，冻结后只允许修 bug 与打磨，突破冻结需负责人签字并同步砍掉等量工作。
使用方式：把当前功能列表、团队人数、可用工时、里程碑日期交给该技能，逐阶段填写清单与评分，最终得到一份范围评估报告，含交通灯状态、MoSCoW 表、评分排序、缓冲计算、蔓延信号数、冻结日期与建议砍掉/保留的功能。核心规则为“一进一出”，新增功能必须砍掉等量工作。
适用场景：独立游戏或小团队的里程碑前评审，接收 game-brainstorm 或 game-design-review 的输入，输出去向 game-sprint-plan。
限制与注意：不适用时缺少功能工时估算或团队产能数据时无法完成测算；缓冲区、比例、评分阈值为该工作流自定规则，并非行业通用标准；文中引用的游戏案例仅用于说明理念；具体执行仍依赖团队成员如实估时。未发现付费或价格信息，暂未提供。