Menu
BuildRail 验收检查。针对单个任务的验收标准，执行验证命令并判断是否通过。 适用于：已有实现代码，需要验证是否满足验收标准。 不要用于：代码审查（用 /br-review）、范围检查（用 /br-scope-check）。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 并说明原因 |