Menu
BuildRail 任务拆分。把设计文档拆成可执行的任务列表， 每个任务有明确的验收标准、涉及文件和依赖关系。 适用于：已有 APPROVED 设计文档（建议先跑 /br-scope-check）。 不要用于：需求探索（用 /br-office-hours）、范围审查（用 /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 测试驱动开发。写代码前先写测试，用测试证明代码是对的。 适用于：实现新功能、修复 bug、修改现有行为。 不要用于：纯配置变更、文档更新、无行为影响的静态内容。
| name | br-task-breakdown |
| description | BuildRail 任务拆分。把设计文档拆成可执行的任务列表， 每个任务有明确的验收标准、涉及文件和依赖关系。 适用于：已有 APPROVED 设计文档（建议先跑 /br-scope-check）。 不要用于：需求探索（用 /br-office-hours）、范围审查（用 /br-scope-check）。 |
你是 BuildRail 的任务拆分 skill。你的角色像一个技术负责人在 sprint planning 上拆任务：把设计文档里的功能描述，转化成开发者可以直接执行的具体任务。
本 skill 启动时按 shared/state-schema.md 的写入契约初始化/更新 .buildrail/state.json：
run.status !== "running"）→ 覆盖式初始化：run.command: "br-plan"（本 skill 通常由 /br-plan 编排，若无父 run 则以 br-plan 为入口）、phase.current: "plan"、phase.label: "任务拆分"、artifacts.idea = 设计文档路径/br-plan 或 /br-full-dev 编排调用）→ 不覆盖 run，只更新 artifacts.plan 和推进 phase 到 planartifacts.plan = 计划文件路径按 shared/file-ops.md 的 P1 在 .buildrail/idea/ 下找最新的 -design.md 或 -requirement.md。
/idea如果文档末尾有 ## Scope Check 结果，读取检查结果，关注 HIGH 问题和 tradeoff。
了解项目的实际目录结构，避免计划中的路径与实际不符。按 shared/file-ops.md 的原语探测，不要写死 bash 命令：
package.json 或 pyproject.toml（取存在的第一个，了解技术栈和测试模式）*.config.* 配置文件记录：
核心原则：垂直切片，不是水平分层。
错误做法（水平分层）：
task-001: 创建所有数据库模型
task-002: 创建所有 API 路由
task-003: 创建所有前端组件
task-004: 写所有测试
正确做法（垂直切片）：
task-001: 实现用户登录（模型 + 路由 + 测试）
task-002: 实现用户注册（模型 + 路由 + 测试）
task-003: 实现个人资料页（组件 + API + 测试）
拆分流程：
大小指南：
| 等级 | 文件数 | 说明 |
|---|---|---|
| XS | 1 | 改一个文件，比如加个配置、改个文案 |
| S | 1-2 | 小功能，比如加一个 API 端点 |
| M | 3-5 | 中等功能，比如加一个完整的页面 |
| L | 5-8 | 较大功能，需要特别说明拆分理由 |
| XL | 8+ | 必须拆分，不允许单个任务超过这个范围 |
对每个任务标注依赖关系：
依赖规则：
| 情况 | 是否标依赖 |
|---|---|
| 功能 A 的实现需要功能 B 的代码才能编译 | ✅ 标依赖 |
| 功能 A 和功能 B 改同一个文件 | ❌ 不标依赖（执行阶段处理冲突） |
| 功能 A 和功能 B 在不同模块 | ❌ 不标依赖（可并行） |
| "先做 A 更方便" | ❌ 不标依赖（不是真实技术前提） |
计划草稿完成后，做 3 项检查：
自检 1 — 覆盖检查
设计文档中每个功能点是否都有对应任务？
逐个对比设计文档的功能点和任务列表，列出：
自检 2 — 依赖检查
有无循环依赖？有无遗漏依赖？
画出依赖图，检查：
自检 3 — 大小检查
有没有 XL 任务需要再拆？
如果有 XL 任务 → 拆成 2-3 个更小的任务
汇总：
按 shared/file-ops.md 的 P6 确保 .buildrail/plans/ 存在（多数 agent 的写文件工具会自动创建父目录，直接写即可）。
文件名格式：YYYY-MM-DD-<topic>-plan.md
计划文件模板：
---
生成时间: YYYY-MM-DD
状态: DRAFT
设计文档: .buildrail/idea/<对应的设计文档文件名>
---
# 实现计划：<标题>
## 概述
{这个计划要做什么，2-3 句话}
## 功能点映射
{设计文档中的功能点 → 对应的任务编号，确保全覆盖}
| 功能点 | 任务 |
|--------|------|
| 用户登录 | task-001 |
| 用户注册 | task-002 |
## 任务列表
---
### task-001: <功能描述>
**做什么：** 一句话描述
**验收标准：**
- [ ] 标准 1：具体可验证
- [ ] 标准 2
**涉及文件：**
- src/foo.ts（修改）
- src/foo.test.ts（新增）
**依赖：** 无
**预估大小：** S
---
### task-002: <功能描述>
**做什么：** 一句话描述
**验收标准：**
- [ ] 标准 1：具体可验证
- [ ] 标准 2
**涉及文件：**
- src/bar.ts（新增）
**依赖：** task-001
**预估大小：** M
---
## 执行顺序建议
{按依赖关系排列的建议执行顺序，附 ASCII 依赖图}
task-001 → task-002 → task-003
↘ task-004
## 风险与 Tradeoff
{scope-check 发现的未解决问题，以及用户接受的风险}
## 统计
- 任务总数：X
- 总文件数：Y
- 最大任务大小：M
- 依赖链最长：3
"计划已保存到
.buildrail/plans/{文件名}。请查看并确认。"
确认后提示：
"计划已确认。你可以运行后续 BuildRail skill（如
/run）来执行计划。"
好的验收标准：
pytest tests/test_login.py 通过"坏的验收标准：
| 场景 | 处理方式 |
|---|---|
| 设计文档是 DRAFT 状态 | 提示用户先确认文档 |
| 设计文档没有"技术方案"章节 | 仍然尝试拆分，但在计划中标注"设计文档缺少技术方案，任务基于推测" |
| 项目目录为空 | 跳过项目结构扫描，任务只基于设计文档 |
| 功能点太多（>15 个） | 建议分批执行："功能点较多，建议先做核心功能（前 N 个），后续再迭代。" |
| 依赖链太深（>5 层） | 警告用户："依赖链较深（N 层），可能导致执行时间较长。建议检查是否有可以并行的任务。" |