القائمة
BuildRail 任务拆分。把设计文档拆成可执行的任务列表， 每个任务有明确的验收标准、涉及文件和依赖关系。 适用于：已有 APPROVED 设计文档（建议先跑 /br-scope-check）。 不要用于：需求探索（用 /br-office-hours）、范围审查（用 /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 测试驱动开发。写代码前先写测试，用测试证明代码是对的。 适用于：实现新功能、修复 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 层），可能导致执行时间较长。建议检查是否有可以并行的任务。" |