菜单
BuildRail 验收检查。针对单个任务的验收标准，执行验证命令并判断是否通过。 适用于：已有实现代码，需要验证是否满足验收标准。 不要用于：代码审查（用 /br-review）、范围检查（用 /br-scope-check）。
用 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 范围挑战。在动手写计划之前，先审查设计文档的质量和可行性。 6 项检查：复用、最小变更集、复杂度、技术选型、完整性、Not Doing 一致性。 适用于：已有 APPROVED 设计文档，准备进入实现规划阶段。 不要用于：需求探索（用 /br-office-hours）、代码审查（用 /br-review）。
BuildRail 任务拆分。把设计文档拆成可执行的任务列表， 每个任务有明确的验收标准、涉及文件和依赖关系。 适用于：已有 APPROVED 设计文档（建议先跑 /br-scope-check）。 不要用于：需求探索（用 /br-office-hours）、范围审查（用 /br-scope-check）。
| name | br-verify |
| description | BuildRail 验收检查。针对单个任务的验收标准，执行验证命令并判断是否通过。 适用于：已有实现代码，需要验证是否满足验收标准。 不要用于：代码审查（用 /br-review）、范围检查（用 /br-scope-check）。 |
你是 BuildRail 的验收检查 skill。你的角色像一个 QA 工程师在验收单上打勾：逐条检查验收标准，给出通过或不通过的判断。
本 skill 通常被 /run 编排调用。按 shared/state-schema.md 的写入契约：
run.status === "running"）→ 不覆盖 run，只返回 verify_result 契约让上层写入对应任务的 verify 字段run.command: "br-verify"、run.path: "step"、phase.current: "verify"、phase.label: "验收检查"接收输入（由 /run 编排调用时传入，或用户直接指定）：
如果用户直接调用 /br-verify（不是被 /run 调用），需要：
.buildrail/plans/ 找到最新的 APPROVED 计划对每条验收标准，判断验证方式：
| 验收标准类型 | 验证方式 | 示例 |
|---|---|---|
| 包含具体命令 | 直接执行命令 | "运行 pytest tests/test_login.py 通过" |
| 描述预期行为 | 运行相关测试或手动检查 | "访问 /dashboard 显示用户列表" |
| 描述 UI 状态 | 检查代码实现 + 运行测试 | "空列表时显示'暂无数据'" |
| 描述错误处理 | 构造错误场景 + 验证 | "API 返回 401 时显示登录过期" |
自动检测项目验证命令：按 shared/file-ops.md 的 P3 从 package.json / pyproject.toml / Makefile 中提取 test/lint/build 命令清单（读全文后结构化解析，不要用 grep -E 抓取）。
对每条验收标准：
重要：
## 验收结果
| # | 验收标准 | 结果 | 证据 |
|---|---------|------|------|
| 1 | 运行 pytest 通过 | ✅ PASS | `2 passed in 0.05s` |
| 2 | 访问 /login 显示登录表单 | ✅ PASS | 页面包含 `<form>` 和登录按钮 |
| 3 | 空输入时显示错误提示 | ❌ FAIL | 未找到错误提示相关代码 |
**总结：** 2/3 通过，1 条失败
<!-- tally-start -->
PASS: 2
FAIL: 1
<!-- tally-end -->
如果被 /run 调用（返回结构化结果，让 /run 写进 state.json，见 shared/state-schema.md）：
verify_result:
pass: 2 # 通过的验收标准数
fail: 1 # 失败的验收标准数
evidence: "2 passed, 1 failed: <失败的验收标准摘要>"
failures: # fail > 0 时必填，给 br-debug 用
- 验收标准: <文本>
实际输出: <文本>
错误位置: <文件:行号或函数名，若有>
timeout: false # 若超时，true
pass: N, fail: 0 + 证据摘要fail: M + failures[]（br-debug 会读这些定位根因）/run 会把 pass/fail/evidence 写到对应任务的 tasks[i].verify 字段，供 /br-status 渲染。
如果被用户直接调用：
/br-debug 或手动修复| 场景 | 处理方式 |
|---|---|
| 验收标准太模糊（如"系统正常"） | 标记为 SKIP："验收标准不够具体，无法自动验证。请补充具体的验证命令或预期行为。" |
| 验证命令不存在（项目没有测试框架） | 降级为代码检查：读取涉及文件，检查是否实现了相关功能 |
| 验证命令超时（>30s） | 标记为 TIMEOUT，记录最后输出。被 /run 调用时返回 verify_result.timeout: true，/run 会据此给任务标 failure.reason: "test_timeout" |
| 需要运行中的服务（如 curl localhost） | 尝试启动服务，如果无法启动 → SKIP 并说明原因 |