scope-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Scope Check

范围检查

This skill is read-only — it reports findings but writes no files.

Compares original planned scope against current state to detect, quantify, and triage scope creep.

Argument:

$ARGUMENTS[0]

— feature name, sprint number, or milestone name.

此技能为只读模式——仅报告结果，不修改任何文件。

通过对比原始计划范围与当前状态，检测、量化并分类处理范围蔓延问题。

参数：

$ARGUMENTS[0]

—— 功能名称、迭代编号或里程碑名称。

Phase 1: Find the Original Plan

阶段1：查找原始计划

Locate the baseline scope document for the given argument:

Feature name → read
```
design/gdd/[feature].md
```
or matching file in
```
design/
```
Sprint number (e.g.,
```
sprint-3
```
) → read
```
production/sprints/sprint-03.md
```
or similar
Milestone → read
```
production/milestones/[name].md
```

If the document is not found, report the missing file and stop. Do not proceed without a baseline to compare against.

定位与给定参数对应的基准范围文档：

功能名称 → 读取
```
design/gdd/[feature].md
```
或
```
design/
```
目录下的匹配文件
迭代编号（例如：
```
sprint-3
```
）→ 读取
```
production/sprints/sprint-03.md
```
或类似文件
里程碑 → 读取
```
production/milestones/[name].md
```

若未找到文档，报告缺失文件并停止操作。必须有基准文档才能进行对比，否则不得继续。

Phase 2: Read the Current State

阶段2：读取当前状态

Check what has actually been implemented or is in progress:

Scan the codebase for files related to the feature/sprint
Read git log for commits related to this work (
```
git log --oneline --since=[start-date]
```
)
Check for TODO/FIXME comments that indicate unfinished scope additions
Check active sprint plan if the feature is mid-sprint

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

扫描代码库中与该功能/迭代相关的文件
读取与此工作相关的git日志（
```
git log --oneline --since=[start-date]
```
）
检查TODO/FIXME注释，这些注释可能表明未完成的范围新增内容
若功能处于迭代中期，检查当前迭代计划

Phase 3: Compare Original vs Current Scope

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

Produce the comparison report:

markdown

undefined

生成对比报告：

markdown

undefined

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]

[当前已实现或正在进行的条目列表]

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]%)

原始条目数：[N]
当前条目数：[N]
新增条目数：[N]（+[X]%）
移除条目数：[N]
范围净变化：[+/-N]（[X]%）

Risk Assessment

风险评估

Schedule Risk: [Low/Medium/High] — [explanation]
Quality Risk: [Low/Medium/High] — [explanation]
Integration Risk: [Low/Medium/High] — [explanation]

进度风险：[低/中/高] —— [说明]
质量风险：[低/中/高] —— [说明]
集成风险：[低/中/高] —— [说明]

Recommendations

建议

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

---

削减：[为保证进度应移除的条目]
延期：[可移至未来迭代/版本的条目]
保留：[确实必要的新增内容]
标记：[需要制作人/创意总监决策的条目]

---

Phase 4: Verdict

阶段4：结论

Assign a canonical verdict based on net scope change:

Net Change	Verdict	Meaning
≤10%	PASS	On Track — within acceptable variance
10–25%	CONCERNS	Minor Creep — manageable with targeted cuts
25–50%	FAIL	Significant Creep — must cut or formally extend timeline
>50%	FAIL	Out of Control — stop, re-plan, escalate to producer

Output the verdict prominently:

**Scope Verdict: [PASS / CONCERNS / FAIL]**
Net change: [+X%] — [On Track / Minor Creep / Significant Creep / Out of Control]

根据范围净变化给出标准结论：

净变化	结论	含义
≤10%	通过	进度正常——在可接受的偏差范围内
10–25%	需关注	轻微蔓延——可通过针对性削减解决
25–50%	不通过	显著蔓延——必须削减范围或正式延长时间线
>50%	不通过	失控——停止工作，重新规划，并上报制作人

突出显示结论：

**范围结论：[通过 / 需关注 / 不通过]**
净变化：[+X%] —— [进度正常 / 轻微蔓延 / 显著蔓延 / 失控]

Phase 5: Next Steps

阶段5：后续步骤

After presenting the report, offer concrete follow-up:

PASS → no action required. Suggest re-running before next milestone.
CONCERNS → offer to identify the 2–3 additions with best cut ratio. Reference
```
/sprint-plan update
```
to formally re-scope.
FAIL → recommend escalating to producer. Reference
```
/sprint-plan update
```
for re-planning or
```
/estimate
```
to re-baseline timeline.

Always end with:

"Run
/scope-check [name]
again after cuts are made to verify the verdict improves."

提交报告后，提供具体的后续行动建议：

通过 → 无需采取行动。建议在下一个里程碑前重新运行此检查。
需关注 → 可协助识别2-3个最适合削减的新增内容。参考
```
/sprint-plan update
```
命令正式重新规划范围。
不通过 → 建议上报制作人。参考
```
/sprint-plan update
```
命令重新规划，或使用
```
/estimate
```
命令重新设定时间基准。

始终以以下内容结尾：

"完成范围削减后，请再次运行
/scope-check [name]
以验证结论是否改善。"

Rules

规则

Scope creep is additions without corresponding cuts or timeline extensions
Not all additions are bad — some are discovered requirements. But they must be acknowledged and accounted for
When recommending cuts, prioritize preserving the core player experience over nice-to-haves
Always quantify scope changes — "it feels bigger" is not actionable, "+35% items" is

范围蔓延指在未对应削减范围或延长时间线的情况下新增内容
并非所有新增内容都是坏事——有些是后续发现的必要需求。但必须对其进行确认并做出相应安排
建议削减范围时，优先保留核心用户体验，而非锦上添花的功能
始终量化范围变化——“感觉范围变大了”不具备可操作性，“条目增加35%”才是可执行的信息