mcpField
S
scope-guard

scope-guard

github.com/athola开发343104 次安装1 天前更新
代码仓库

关于 scope-guard

scope-guard 是帮助 Claude 和开发者在构思、规划与执行中避免过度设计的开发 Skill。它根据价值、成本、待办队列和分支限制评估提案，并引导实施、讨论或延期。

主要功能

  1. 01功能价值评分
  2. 02与待办队列比较
  3. 03检查分支预算
  4. 04记录功能决策
  5. 05监控分支阈值

适用场景

  1. 01设计前评估功能提案
  2. 02根据待办项和分支容量检查计划
  3. 03延期创意并记录 GitHub Issue

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/athola/claude-night-market --skill scope-guard

安装后在 Claude Code 中输入/scope-guard确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

modules/
anti-overengineering.md
baseline-scenarios.md
branch-management.md
decision-framework.md
github-integration.md

详细介绍

最便宜的功能，就是你从未构建的功能。 Scope-guard 会根据每项提议功能的价值、 成本和分支预算进行权衡，只交付值得实现的功能。

Scope Guard

在头脑风暴、规划和执行工作流中，防止 Claude 和人类过度设计。强制对每项提议功能的业务价值、机会成本和分支限制进行明确评估。

理念

核心信念： 并非所有功能都值得实现。大多数想法都应暂缓，放入待办列表，直到证明确有必要。

三大支柱：

  1. 价值评分 - 在构建前量化价值与成本
  2. 机会成本 - 与现有待办事项进行比较
  3. 分支纪律 - 遵守规模阈值

适用场景

  • 在头脑风暴阶段、记录设计之前
  • 在规划阶段、敲定实施计划之前
  • 评估“我们是否应该添加这个？”这类决策时
  • 当分支接近阈值时，通过钩子自动触发
  • 提议新功能、抽象或模式时

不适用场景

  • 范围明确且有限的 Bug 修复
  • 仅涉及文档的更改
  • 简单的单文件编辑（< 50 行）
  • 紧急的生产环境修复

快速开始

1. 为功能评分

使用价值评分公式：

(Business Value + Time Criticality + Risk Reduction) / (Complexity + Token Cost + Scope Drift)

验证： 使用 --help 标志运行命令，以确认命令可用。

详情请参阅 decision-framework.md。

阈值：

  • > 2.0 → 立即实施
  • 1.0 - 2.0（含） → 先讨论
  • < 1.0 → 暂缓，放入待办列表
2. 与待办列表进行比较

与 docs/backlog/queue.md 进行比较：

  • 它是否优于排在最前面的待办事项？
  • 分支预算是否有余量？
3. 确认分支预算

默认值：每个分支 3 项主要功能

如果已达上限，必须移除现有功能、拆分到新分支，或说明覆盖限制的理由。

4. 监控阈值

留意黄色/红色区域：

  • 行数： 1000/1500/2000
  • 提交数： 15/25/30
  • 天数： 3/7/7+

监控详情请参阅 branch-management.md。

核心工作流

步骤 1：计算价值评分（scope-guard:worthiness-scored）

为每个因素评分（1、2、3、5、8、13）：

  • 价值因素： 业务价值、时间紧迫性、风险降低
  • 成本因素： 复杂性、Token 成本、范围偏移

详情：decision-framework.md

步骤 2：与待办列表进行比较（scope-guard:backlog-compared）
  1. 检查 docs/backlog/queue.md 中的现有事项
  2. 比较价值评分
  3. 新事项必须优于排在最前面的待办事项，或符合分支预算
步骤 3：检查分支预算（scope-guard:budget-checked）

统计分支中的当前功能数。如果已达到预算（默认值：3），新增功能必须满足以下任一条件：

  • 移除一项现有功能，或
  • 拆分到新分支，或
  • 明确说明覆盖限制的理由
步骤 4：记录决策（scope-guard:decision-documented）

记录结果：

  • 实施： 记录价值评分和预算名额
  • 暂缓（必须完成以下步骤）：
    1. 立即创建 GitHub issue - 参阅 github-integration.md 中的步骤 1-3
    2. 标记 scope-guard:github-issue-created 为已完成
    3. 创建 Discussion - 参阅 github-integration.md 中的步骤 4。 提示词：“正在创建包含完整理由背景的 Discussion。[Y/n]” 默认会发布。如果用户明确拒绝，则跳过创建 Discussion。如果发布失败，则继续。
    4. 可选：将事项连同 issue 链接添加到 docs/backlog/queue.md
  • 拒绝： 记录原因（价值低、不在范围内）

重要： 必须先创建 GitHub issue，暂缓才算完成。这样可以避免分支合并或废弃时丢失上下文。

反过度工程规则

核心原则：

  • 在提出解决方案之前，先提出澄清问题
  • 第 3 个使用场景出现之前，不要进行抽象
  • 推迟实现“锦上添花”的功能
  • 不要超出分支预算

完整规则和危险信号请参阅 anti-overengineering.md。

待办事项管理

目录结构
**Verification:** Run the command with `--help` flag to verify availability.
docs/backlog/
├── queue.md              # Active ranked queue
└── archive/
    ├── ideas.md          # Deferred feature ideas
    ├── optimizations.md  # Deferred performance work
    ├── refactors.md      # Deferred cleanup
    └── abstractions.md   # Deferred patterns

验证： 使用 --help 标志运行命令，确认其可用。

队列规则
  • 活跃队列最多包含 10 个项目
  • 超过 30 天无人认领的项目 → 移入存档
  • 每月重新评分，或在项目背景发生变化时重新评分
添加到队列

推迟事项时，将其添加到 docs/backlog/queue.md：

| Rank | Item | Worthiness | Added | Branch/Epic | Category |
|------|------|------------|-------|-------------|----------|
| 1 | [New item description] | 1.8 | 2025-12-08 | current-branch | idea |

验证： 使用 --help 标志运行命令，确认其可用。

添加后，按价值评分重新排序。

集成点

与 superpowers:brainstorming 集成

在头脑风暴结束时、记录设计之前：

  1. 列出所有提议的功能/组件
  2. 使用价值公式为每项评分
  3. 将评分 < 1.0 的项目推迟到待办事项列表
  4. 检查其余项目是否符合分支预算

自行调用提示词：“在记录此设计之前，我先用 scope-guard 评估提议的功能。”

与 superpowers:writing-plans 集成

在最终确定实施计划之前：

  1. 确认所有计划项目的价值评分 >= 1.0，并且“讨论”区间内的每项都附有理由
  2. 与待办事项队列进行比较
  3. 确认未超出分支预算
  4. 记录所有推迟事项

自行调用提示词：“在最终确定此计划之前，我先用 scope-guard 检查范围。”

在 superpowers:executing-plans 期间

执行过程中定期进行：

  1. 运行阈值检查：行数、文件数、提交数、天数
  2. 达到黄色区域时发出警告
  3. 达到红色区域时要求提供理由

自行调用提示词：“此分支已大幅增长。我来检查 scope-guard 阈值。”

必需的进度事项

评估功能时，创建以下待办事项：

  1. scope-guard:worthiness-scored
  2. scope-guard:backlog-compared
  3. scope-guard:budget-checked
  4. scope-guard:github-issue-created（推迟事项时为强制要求——未完成此项不得进入第 5 步）
  5. scope-guard:decision-documented

**注意：**推迟项目时，第 4 项（github-issue-created）为必需项。推迟事项未先完成 github-issue-created，就不能将 decision-documented 标记为已完成。

相关技能

  • superpowers:brainstorming - 受此规则约束的构思工作流
  • superpowers:writing-plans - 此规则验证的计划工作流
  • imbue:review-core - 审查方法模式
  • imbue:karpathy-principles - 涵盖范围、简洁性、精准修改和可验证目标的紧凑四原则总结
  • 完整的关卡技能联邦图请参阅 docs/quality-gates.md#skill-level-quality-gate-composition

模块参考

退出标准

  • 每项提议的功能都已根据公式 (Business Value + Time Criticality + Risk Reduction) / (Complexity + Token Cost + Scope Drift) 计算 Worthiness Score，并确定处理方式： 实施（>2.0）、讨论（1.0-2.0）或暂缓（<1.0）
  • 暂缓的事项在 scope-guard:decision-documented 标记为完成之前，已创建 GitHub issue；issue URL 已记录在待办事项中
  • 已检查分支预算：如果已有 3 项主要功能，新增功能必须舍弃一项现有功能、拆分到新分支，或提供明确的书面豁免及理由
  • 已检查分支阈值区间（行数 1000/1500/2000，提交数 15/25/30，天数 3/7/7+）；黄色区间会触发警告，红色区间在没有理由时会阻止操作

评论

支持 Markdown