scope-check

范围检查

此技能为只读：它会报告发现，但不会写入文件。

比较原始计划范围与当前状态，以检测、量化并分级处理范围蔓延。

参数： $ARGUMENTS — 完整字符串：功能名称（可以包含多个词）、迭代编号或里程碑名称。

---

阶段 1：查找原始计划

根据给定参数定位基准范围文档：

• 功能名称 → 读取 design/gdd/[feature].md 或 design/ 中的匹配文件
• 迭代编号（例如 sprint-3）→ 读取 production/sprints/sprint-003.md（/sprint-plan 写入的名称）或类似文件
• 里程碑 → 读取 production/milestones/[name].md

如果找不到文档，报告缺失文件并停止。没有基准可供比较时，不要继续。 按章节读取 GDD：使用 Grep 工具查找所需标题（模式 ^#，内容模式），然后使用 Read 工具通过 offset 和 limit 读取相应范围。

---

阶段 2：读取当前状态

检查实际已实现或正在进行的内容：

• 扫描代码库中与该功能／迭代相关的文件
• 阅读与此工作相关的 git log 提交记录（git log --oneline --since=[start-date]）
• 检查是否有表明范围新增但尚未完成的 TODO/FIXME 注释
• 如果功能处于迭代中期，检查当前迭代计划

---

阶段 3：比较原始范围与当前范围

生成比较报告：

## Scope Check: [Feature/Sprint Name]
Generated: [Date]

### Original Scope
[List of items from the original plan]

### Current Scope
[List of items currently implemented or in progress]

> **If Phase 4 will return NOT ASSESSED, do not render the numeric block below.**
> Replace the counts and the Bloat Score with
> `[Baseline | Current state] unusable — see verdict` (whichever side could not
> be read) and give the reason. A rendered
> `Original items: 0 / Net scope change: 0%` one section above a NOT ASSESSED
> verdict re-creates the exact "0% reads as on track" hazard Phase 4 exists to
> kill, one phase earlier — and readers trust a number over a caveat.

### Scope Additions (not in original plan)
| Addition | Source | When | Justified? | Effort |
|----------|--------|------|------------|--------|
| [item] | [commit/person] | [date] | [Yes/No/Unclear] | [S/M/L] |

### Scope Removals (in original but dropped)
| Removed Item | Reason | Impact |
|-------------|--------|--------|
| [item] | [why removed] | [what's affected] |

### Bloat Score
- Original items: [N]
- Current items: [N]
- Items added: [N] (+[X]%)
- Items removed: [N]
- Net scope change: [+/-N] ([X]%)

### Risk Assessment
- **Schedule Risk**: [Low/Medium/High] — [explanation]
- **Quality Risk**: [Low/Medium/High] — [explanation]
- **Integration Risk**: [Low/Medium/High] — [explanation]

### Recommendations
1. **Cut**: [Items that should be removed to stay on schedule]
2. **Defer**: [Items that can move to a future sprint/version]
3. **Keep**: [Additions that are genuinely necessary]
4. **Flag**: [Items that need a decision from producer/creative-director]

---

阶段 4：判定

根据净范围变更指定规范判定结果：

净变更	判定	含义
≤10%	PASS	按计划推进 — 在可接受的偏差范围内
>10–25%	CONCERNS	轻微蔓延 — 可通过有针对性的删减来控制
>25–50%	FAIL	明显蔓延 — 必须删减范围或正式延长时间线
>50%	FAIL	失控 — 停止、重新规划并升级给制作人

在应用该表格之前，先确认百分比是否有意义。 在以下任一情况下，应输出 NOT ASSESSED，而不是计算百分比：

• 基准文档存在，但未列出任何范围事项（全部是标题、占位内容或 [TO BE CONFIGURED]）。如果文件不存在，阶段 1 就会停止；此处指文件存在但内容为空。这种情况更危险，因为零个事项会得出 0% 的净变更，从而显示 PASS — 按计划推进。实际上没有进行比较，也无从判断是否按计划推进。
• 无法确定当前状态 — 没有相关源文件、时间范围内没有提交记录，也没有可供查阅的进行中工作。将真实基准与无法读取的当前状态进行比较，既不是 0% 变更，也不是按当前事项为零计算出的 −100%；这两种结果都会被表格判为 PASS。
• 由于其他原因导致分母为零。 根据不存在的基准事项计算出的百分比，不是一个小数字，而根本不是一个数字。

NOT ASSESSED 优先于 PASS（未进行比较就不能证明范围按计划推进），但低于 CONCERNS 和 FAIL（已测得的蔓延比无法衡量的基准更有助于采取行动）。

在显眼位置输出判定结果：

**Scope Verdict: [PASS / CONCERNS / NOT ASSESSED / FAIL]**
Net change: [+X%] — [On Track / Minor Creep / Significant Creep / Out of Control]
           [or: NOT ASSESSED — [which side could not be read, and why]]

---

阶段 5：后续步骤

呈现报告后，提供具体的后续建议：

• PASS → 无需采取行动。建议在下一个里程碑前重新运行。
• NOT ASSESSED → 说明哪一方无法读取，以及如何解决（填写基线文档，或告知该技能实际工作内容所在的位置）。 不要建议使用相同输入重新运行——这样仍会得到相同的无结论结果。
• CONCERNS → 提议找出削减比例最佳的 2–3 项新增内容。提及 /sprint-plan update，以正式调整范围（如果项目没有冲刺计划，例如默认的最简工作流，则通过编辑简报中的构建顺序来调整范围）。
• FAIL → 建议向制片人升级处理。提及 /sprint-plan update 以重新规划（如果项目没有冲刺计划，例如默认的最简工作流，则编辑简报中的构建顺序），或使用 /estimate 重新设定时间线基准。

除 NOT ASSESSED 外，每种判定结尾都使用：

“完成削减后，再次运行 /scope-check [name]，以验证判定结果是否有所改善。”

（NOT ASSESSED 的结尾应说明如何使其具备评估条件，见上文——使用相同输入重新运行只会重复得到无结论结果。）

---

规则

• 范围蔓延是指增加内容，却没有相应削减内容或延长时间线
• 并非所有新增内容都是坏事——有些是发现的需求。但必须承认并妥善处理
• 建议削减时，优先保留核心玩家体验，而非锦上添花的内容
• 始终量化范围变化——“感觉内容更多了”不可执行，“项目项增加了 35%”才可执行