有规格或需求后如何拆解为可执行任务：先规划再编码…

当你已有规格或明确需求，需要把工作拆成可实施、可验证的小任务时使用。

适用场景

解决思路

1. 进入规划模式：在写任何代码前先只读地阅读规格与相关代码库，识别既有模式与约定，梳理组件间依赖，记录风险与未知项；规划阶段不要写代码，产出是保存到 tasks/plan.md 的计划文档和记录在任务列表目标（默认 tasks/todo.md）中的任务清单。
2. 绘制依赖图：明确什么依赖什么（如数据库 schema → API 模型/类型 → API 端点 → 前端 API 客户端 → UI 组件，以及校验逻辑、种子数据/迁移），实现顺序按依赖图自底向上，先建基础。
3. 垂直切片而非水平切片：不要先建完整个数据库、再建所有 API、再建所有 UI；而是一次构建一条完整功能路径（如任务1：用户可注册 = 注册的 schema + API + UI；任务2：用户可登录；任务3：用户可创建任务；任务4：用户可查看任务列表），每个垂直切片交付可运行、可测试的功能。
4. 按固定结构编写每个任务：标题、一段描述、验收标准（具体可测试的条件清单）、验证步骤（测试通过：仓库的聚焦测试命令；构建成功：仓库的构建命令；人工检查：需验证内容的描述）、依赖（依赖的任务编号或 None）、可能涉及的文件路径、预估规模（Small: 1-2 文件 | Medium: 3-5 文件 | Large: 5+ 文件）。
5. 排序并设置检查点：确保依赖先满足（先建基础）、每个任务完成后系统仍处于可工作状态、每 2-3 个任务后设验证检查点、高风险任务前置（尽早失败）；在任务列表目标中显式写入检查点（如“检查点：任务 1-3 之后：所有测试通过、应用无错误构建、核心用户流程端到端可用、继续前与人工评审”）。
6. 按规模指南控制任务大小：XS=1 文件（单个函数或配置变更）、S=1-2 文件（一个组件或端点）、M=3-5 文件（一个功能切片）、L=5-8 文件（多组件功能）、XL=8+ 文件（太大，必须继续拆分）；L 及以上应拆小，agent 在 S 和 M 任务上表现最好。
7. 满足以下任一条件就继续拆分任务：需要超过一个专注会话（约 2 小时以上 agent 工作）、验收标准无法用 3 条以内要点描述、涉及两个或以上独立子系统（如认证与计费）、任务标题里出现“和”（说明它其实是两个任务）。
8. 管理输出文件：计划文档始终保存为 tasks/plan.md（设计决策、风险、开放问题不适合放进单个 tracker issue）；每个任务记录到任务列表目标；若 tasks/ 目录不存在则创建。
9. 绝不覆盖未完成的计划：写 tasks/plan.md 或 tasks/todo.md 前先检查是否已存在且仍有未勾选任务；若是同一工作在重新规划（用户要求修订或扩展该计划）则就地更新；若是不同工作则停下并询问，不要自行删除、覆盖或重命名已有文件，把冲突呈现给用户决定（先完成旧计划、明确丢弃、或指定新计划位置）；对外部任务列表目标同样适用，绝不为腾地方而批量关闭或删除另一个计划的未完成 tracker 项。
10. 确定任务列表目标：默认使用 checklist 风格的 markdown 文件 tasks/todo.md（/build 命令及下游工具期望的约定），除非项目另有规定；若项目 agent 规则（CLAUDE.md、AGENTS.md 等）或用户指定了 issue tracker（如 GitHub Issues、Jira、Linear、bd/beads），则每个任务创建一个 tracker 项而不写 tasks/todo.md，把 Step 4 的结构映射到 tracker 字段（验收标准与验证步骤放正文，依赖用 tracker 的链接机制如 bd dep add、“blocked by”），检查点也记为 tracker 项或写在计划文档的 checklist 中；使用外部 tracker 时在 tasks/plan.md 注明（如“Tasks tracked in Linear project FOO”），并让计划文档的任务列表部分作为 tracker 项 ID 或链接的有序索引而非重复 checklist。
11. 按计划文档模板组织内容：概览（一段话总结要构建什么）、架构决策（关键决策及理由）、任务列表（按阶段分组，如 Phase 1: Foundation、Checkpoint: Foundation、Phase 2: Core Features、Checkpoint: Core Features、Phase 3: Polish、Checkpoint: Complete）、风险与缓解（表格：风险 | 影响 High/Med/Low | 缓解策略）、开放问题（需要人工输入的问题）。
12. 识别并行化机会：可安全并行的是独立功能切片、已实现功能的测试、文档；必须串行的是数据库迁移、共享状态变更、依赖链；需要协调的是共享 API 契约的功能（先定义契约，再并行）。
13. 警惕常见借口并纠正：“我边做边想”会导致混乱和返工，10 分钟规划省下数小时；“任务很明显”也要写下来，显式任务能暴露隐藏依赖和被遗忘的边界情况；“规划是额外开销”其实规划就是任务本身，没有计划的实现只是打字；“我能全记在脑子里”但上下文窗口有限，写下的计划能跨会话和压缩存活；“旧的 tasks/plan.md 过时了直接替换”但未勾选任务可能正在另一个会话中构建，覆盖会毁掉别处不存在的状态，应停下询问。
14. 避开红旗信号：没有书面任务清单就开始实现；未询问就覆盖仍有未勾选任务（且属于不同工作）的 tasks/plan.md 或 tasks/todo.md；项目已指定外部 tracker 却写 tasks/todo.md（或两边散落任务）；任务只说“实现该功能”而无验收标准；计划中没有验证步骤；所有任务都是 XL 规模；任务之间没有检查点；未考虑依赖顺序。
15. 开始实现前逐项确认验证清单：每个任务都有验收标准；每个任务都有验证步骤；任务依赖已识别且顺序正确；任务已记录到任务列表目标（默认 tasks/todo.md）；未在未经用户明确确认下覆盖任何已存在的未完成计划；没有任务涉及超过约 5 个文件；主要阶段之间有检查点；人工已评审并批准该计划。
16. 注意验收标准是逐任务的，回答“我们是否构建了正确的东西”，它们建立在项目级 Definition of Done 之上（每个任务在算作完成前都要达到的固定标准），参见 ../../references/definition-of-done.md。

适用边界 · 注意事项

• 单文件改动且范围明确时
• 规格中已经包含定义良好的任务时