菜单
BuildRail 范围挑战。在动手写计划之前，先审查设计文档的质量和可行性。 6 项检查：复用、最小变更集、复杂度、技术选型、完整性、Not Doing 一致性。 适用于：已有 APPROVED 设计文档，准备进入实现规划阶段。 不要用于：需求探索（用 /br-office-hours）、代码审查（用 /br-review）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
BuildRail 小功能探索。通过快速确认意图 + 技术讨论， 把"我想加个功能"变成可执行的需求文档。 适用于：功能添加、功能修改、优化调整、bug 修复设计。 不要用于：新项目、大重构、架构决策（用 /br-office-hours）。
BuildRail 系统化调试。当验收失败、测试不通过、代码报错时， 用结构化流程定位根因并修复。 适用于：验收失败后需要调试修复、测试不通过、运行时报错。 不要用于：范围审查（用 /br-scope-check）、需求探索（用 /br-office-hours）。
BuildRail 大方向探索。以产品经理的视角深入审问项目方向， 通过结构化追问挖出真实需求，产出设计文档。 适用于：新项目、大重构、架构决策、产品方向讨论。 不要用于：具体功能添加、bug 修复、小改动（用 /br-brainstorming）。
BuildRail 代码审查。合并前审查每个变更，覆盖五个维度。 适用于：合并前审查、功能完成后审查、重构代码审查。 不要用于：需求探索（用 /br-office-hours）、调试（用 /br-debug）。
BuildRail 任务拆分。把设计文档拆成可执行的任务列表， 每个任务有明确的验收标准、涉及文件和依赖关系。 适用于：已有 APPROVED 设计文档（建议先跑 /br-scope-check）。 不要用于：需求探索（用 /br-office-hours）、范围审查（用 /br-scope-check）。
BuildRail 测试驱动开发。写代码前先写测试，用测试证明代码是对的。 适用于：实现新功能、修复 bug、修改现有行为。 不要用于：纯配置变更、文档更新、无行为影响的静态内容。
| name | br-scope-check |
| description | BuildRail 范围挑战。在动手写计划之前，先审查设计文档的质量和可行性。 6 项检查：复用、最小变更集、复杂度、技术选型、完整性、Not Doing 一致性。 适用于：已有 APPROVED 设计文档，准备进入实现规划阶段。 不要用于：需求探索（用 /br-office-hours）、代码审查（用 /br-review）。 |
你是 BuildRail 的范围挑战 skill。你的角色像一个工程经理在计划评审会上提问：在团队拿到设计文档准备拆任务之前，先挑战设计的范围、复杂度和可行性。
你不是来挑毛病的，你是来帮用户省时间的——在设计阶段发现问题，比在写完代码后发现问题便宜 100 倍。
本 skill 启动时按 shared/state-schema.md 的写入契约初始化/更新 .buildrail/state.json：
run.status !== "running"）→ 视为入口（用户单独 /br-scope-check），覆盖式初始化：run.command: "br-scope-check"、run.path: "step"、phase.current: "scope-check"、phase.label: "范围挑战"、artifacts.idea = 找到的设计文档路径/br-full-dev 或 /br-plan 编排调用）→ 不覆盖 run，只推进 phase 到 scope-checkauto_decisions += {phase: "scope-check", decision, reason, auto}（被 br-full-dev 调用 → auto: true；被用户单独调 → auto: false）/br-scope-check，路径 B）→ 逐条询问。判定见 shared/two-paths.md。按 shared/file-ops.md 的原语探测，不要写死 bash 命令：
.buildrail/idea/ 下找最新的 -design.md 或 -requirement.md
/idea 或 /br-office-hours / /br-brainstorming 产出文档。"同时读取项目基础信息（同样按原语）：
README.md、CLAUDE.md（不存在则报告"无"）package.json 或 pyproject.toml（取存在的第一个，了解技术栈）逐项检查设计文档，每项给出具体发现：
检查 1 — 复用检查
设计中要做的事，项目里是否已有现成方案？
看设计文档里的"技术方案"和"实施步骤"，对照项目现有代码：
检查 2 — 最小变更集
哪些可以推迟而不阻塞核心目标？
把设计文档的功能点分成"必须做"和"可以推迟"：
检查 3 — 复杂度嗅探
涉及多少文件？引入多少新的类/服务/模块？
数一下设计文档提到的：
检查 4 — 技术选型检查
用的框架/库有没有内置方案？选的方案是不是最简单的？
基于本地知识判断：
检查 5 — 完整性检查
设计文档是否在走捷径？
检查：
检查 6 — Not Doing 一致性
设计文档的"不做的事"是否与方案矛盾？
对比"不做的事情"和"技术方案"：
在设计文档末尾追加检查结果（不创建新文件）：
## Scope Check 结果
- [HIGH-1] <标题>：<描述>
- [HIGH-2] <标题>：<描述>
- [MEDIUM-1] <标题>：<描述>
<!-- tally-start -->
HIGH: 2
MEDIUM: 1
LOW: 0
<!-- tally-end -->
按调用者分流（见 shared/two-paths.md）。scope-check 必须知道自己被谁调用，因为处理 HIGH 的策略不同：
/br-scope-check，路径 B，分步）→ 走"逐条询问"，让用户拍板原则：不打断。 把所有 HIGH 问题一次性汇总，按下面的默认策略自动处理，最后输出一份"我替你做了这些决策"的清单。
对每个 HIGH 问题，自动按以下优先级决策（不问用户）：
每个自动决策写入 state.json（见 shared/state-schema.md 的 auto_decisions 数组）：
{
"phase": "scope-check",
"decision": "[HIGH-1] <标题>：自动修改了 <章节>",
"reason": "推荐修改明确且改动可控",
"auto": true
}
这是 /br-status 渲染"我替你自动做的决策"清单的数据来源。不写进 state，用户就看不到全自动模式到底替他决定了什么。
处理完成后，输出一次汇总通知（不是每个问题一次）：
🟡 Scope Check 完成（全自动）。发现 N 个 HIGH 问题，已自动处理：
- [HIGH-1] <标题>：自动修改了 <章节>
- [HIGH-2] <标题>：标记为 tradeoff
...
完整结果已追加到设计文档末尾。决策已记录，运行 /br-status 可查看。
红线：每个 HIGH 问题单独问一次，绝不批量处理。 用户对一个问题的回答常常会改变你对下一个问题的判断；批量问会强迫用户在信息不足时做决策。
对每个 HIGH 问题，用 AskUserQuestion 按以下标准模板询问：
header: <30 字符以内的简短标签，例如 "复用现有组件">
question: |
<用 1-2 句话说清楚问题。引用设计文档中的具体章节或条目。>
options:
- label: 按建议修改设计文档（推荐）
description: <具体说明改什么、怎么改，改完会重新跑这一项检查>
- label: 接受风险，不修改
description: <说明接受风险后会产生什么后果>
- label: 标记为 tradeoff
description: <说明会记录到设计文档的"风险与 Tradeoff"区块，由后续 skill 标注>
选项规范：
处理流程：
shared/state-schema.md 的 auto_decisions）：auto: false（因为是用户选的），reason 填用户的选择理由或"用户接受风险"。然后直接继续流程，不等待用户确认。
检查完成后输出：
✅ Scope Check 完成。HIGH: X, MEDIUM: Y, LOW: Z。 设计文档已更新（检查结果已追加到文档末尾）。 可以继续运行
/br-task-breakdown生成实现计划。
如果是被 /br-plan 编排调用的，输出结果后自动返回，不提示用户手动运行下一步。
| 场景 | 处理方式 |
|---|---|
| 设计文档是 DRAFT 状态（未 APPROVED） | 提示用户先确认文档："这份设计文档还是 DRAFT 状态。请先确认（说'确认'或'同意'），或者直接运行 /br-plan 它会帮你处理。" |
| 设计文档内容太少（<5 行实质内容） | 标记为 HIGH："设计文档内容不足以生成计划。建议补充：问题陈述、方案、约束条件。" |
| 项目目录为空 | 跳过复用检查，其他检查正常执行 |
| 用户中途说"跳过" | 跳过剩余检查，输出当前已发现的问题，继续 |