‹ 首页

scope-check

@pixel-cellar · 收录于 5 天前 · 上游提交 4 个月前

通过将当前范围与原始计划进行对比,分析功能或 Sprint 的范围蔓延(Scope Creep)。标记新增项,量化膨胀程度,并推荐裁剪方案。

适合你,如果常因需求膨胀导致项目延期

/ 通过 npx 安装 校验哈希
npx oh-my-skill add pixel-cellar/claude-code-game-studios/scope-check
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- pixel-cellar/claude-code-game-studios/scope-check
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify pixel-cellar/claude-code-game-studios/scope-check
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
273GitHub stars
~887上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 2c016ef · 表述以原文为准
它做什么

当你提供功能名称或Sprint编号时,Claude会读取相关设计文档、Git日志和代码,对比原始计划与当前实现,生成范围检测报告,标记新增项、量化膨胀百分比,并给出裁剪建议和风险评估。

什么时候触发

当你直接询问某个功能或Sprint的范围检查时触发,例如说出功能名或Sprint编号。

装好后可以这样说
Claude会读取设计文档和代码并生成报告。
Claude会对比Sprint计划与实际进展。
技能原文 SKILL.md作者撰写 · MIT · 2c016ef

当此技能被调用时:

  1. 读取原始计划 — 找到相关文档:
  2. 如果是功能名称:从 design/gdd/ 读取设计文档
  3. 如果是 Sprint 编号:从 production/sprints/ 读取 Sprint 计划
  4. 如果是里程碑:从 production/milestones/ 读取里程碑定义
  1. 读取当前状态 — 检查实际已实现或正在进行的部分:
  2. 扫描代码库中与该功能/Sprint 相关的文件
  3. 读取 Git 日志中与此工作相关的提交
  4. 检查指示未完成范围新增的 TODO 注释
  1. 对比原始范围与当前范围

```markdown ## 范围检查: [Feature/Sprint Name] 生成时间: [Date]

### 原始范围 [原始计划中的项目列表]

### 当前范围 [当前已实现或正在进行的项目列表]

### 新增范围(不在原始计划中) | 新增项 | 添加者 | 时间 | 有依据? | 工作量 | |--------|--------|------|----------|--------| | [item] | [commit/person] | [date] | [是/否/不明确] | [小/中/大] |

### 移除范围(在原始计划中但已取消) | 移除项 | 原因 | 影响 | |--------|------|------| | [item] | [移除原因] | [受影响的内容] |

### 膨胀评分

  • 原始项目数: [N]
  • 当前项目数: [N]
  • 新增项目数: [N] (+[X]%)
  • 移除项目数: [N]
  • 净范围变化: [+/-N] ([X]%)

### 风险评估

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

### 建议

  1. 裁剪: [为按时交付应移除的项目]
  2. 延期: [可移至未来 Sprint/版本的项目]
  3. 保留: [确实必要的新增项]
  4. 标记: [需要制作人(Producer)/创意总监(Creative Director)决策的项目] ```
  1. 输出范围检查结果,附带明确结论:
  2. 正常: 范围在原始计划的 10% 以内
  3. 轻微蔓延: 范围增加 10-25% — 通过调整可管理
  4. 显著蔓延: 范围增加 25-50% — 需要裁剪或延长工期
  5. 失控: 范围增加 >50% — 停止并重新规划
规则
  • 范围蔓延是指在没有相应裁剪或工期延长的情况下新增内容
  • 并非所有新增都是坏事 — 有些是发现的需求。但必须被确认并纳入考量
  • 在推荐裁剪时,优先保护核心玩家体验,而非锦上添花的功能
  • 始终量化范围变化 — "感觉变大了"不可操作,"+35% 的项目数"才是
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。