Task [N]: [Short descriptive title]

Task [N]: [Short descriptive title]

Description: One paragraph explaining what this task accomplishes.

Acceptance criteria:

• [ ] [Specific, testable condition]
• [ ] [Specific, testable condition]

Verification:

• [ ] Tests pass: [the repository's focused-test command]
• [ ] Build succeeds: [the repository's build command]
• [ ] Manual check: [description of what to verify]

Dependencies: [Task numbers this depends on, or "None"]

Files likely touched:

• src/path/to/file.ts
• tests/path/to/test.ts

Estimated scope: [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]

六个字段各有用意:验收标准回答"做对了什么",验证步骤回答"怎么证明",依赖声明让排序可推导,"Files likely touched"帮助控制改动半径,范围估计则强制任务保持在可执行粒度。

### 第 5 步:排序并插入检查点

任务排列需同时满足四条:依赖先满足(先建地基);**每个任务结束后系统都处于可工作状态**;每 2~3 个任务后出现验证检查点;高风险任务前置(快速失败)。技能给出的检查点写法:

```markdown
## Checkpoint: After Tasks 1-3
- [ ] All tests pass
- [ ] Application builds without errors
- [ ] Core user flow works end-to-end
- [ ] Review with human before proceeding

检查点的最后一项与 /plan 命令的第六步"Present the plan for human review"呼应:人机协作的边界被显式写进了任务清单本身。

任务粒度:XS/S/M/L/XL 分级与拆分判据

SKILL.md 用一张表定义任务粒度,并给出明确结论:Agent 在 S 和 M 级任务上表现最好,L 及以上必须继续拆分。

尺寸	文件数	范围	示例
XS	1	单个函数或配置变更	添加一条校验规则
S	1-2	一个组件或端点	添加一个新 API 端点
M	3-5	一个功能切片	用户注册流程
L	5-8	多组件功能	带过滤和分页的搜索
XL	8+	太大——必须继续拆	—

四个"该继续拆分"的判据,任何一个命中就拆:

• 预计超过一个专注会话(约 2 小时以上的 Agent 工作量);
• 验收标准无法用 3 条以内的要点写完;
• 涉及两个及以上相互独立的子系统(如认证与计费);
• 任务标题里出现了 "and"(and 是"这是两个任务"的信号)。

产物与防覆盖机制:tasks/plan.md 与 tasks/todo.md

这是 /plan 命令最具工程约束力的部分,技能中称为 Output Files:

• 计划文档:始终保存为 tasks/plan.md,且始终是 markdown——因为设计决策、风险、开放问题无法映射到单个跟踪条目上。
• 任务清单:记录到"任务清单目标"(Task List Target)。

任务清单目标有两种取值:

1. 默认:checklist 风格的 markdown 文件 tasks/todo.md。这是 /build 命令与其他下游工具约定的格式,除非项目另有指定,否则一律用它。
2. 外部跟踪器:如果项目的 Agent 规则文件(CLAUDE.md、AGENTS.md 等)或用户指定了 issue 跟踪系统(如 GitHub Issues、Jira、Linear、bd/beads),则每个任务建一个跟踪条目,把第 4 步模板映射到跟踪器字段(验收标准与验证步骤放正文,依赖用跟踪器的链接机制如 bd dep add、"blocked by" 表达),检查点同样记录为条目或计划文档中的清单。使用外部跟踪器时,必须在 tasks/plan.md 中注明位置(如 "Tasks tracked in Linear project FOO"),并把计划文档的 Task List 一节保留为条目 ID 的有序索引而非重复清单。

防覆盖规则分三种情形:

• 若 tasks/plan.md / tasks/todo.md 已存在且含未勾选任务,且是同一份工作的重规划 → 原地更新现有文件;
• 若是不同工作 → 停下来问。未勾选任务可能正在另一会话中构建,不得自行删除、覆盖或重命名;把冲突摆出来,由用户决定(先完成旧计划、明确废弃它,或指定新计划放哪里);
• 同样的规则适用于外部跟踪器:绝不能为了腾位置而批量关闭/删除另一份计划的开放条目。

tasks/ 目录不存在时创建即可。这套规则与 /plan 命令正文最后一句("stop and ask before writing — never silently overwrite an incomplete plan")完全一致。

计划文档模板

SKILL.md 给出 tasks/plan.md 的标准骨架,包含概览、架构决策、分阶段任务列表(每阶段后跟检查点)、风险缓解表和开放问题:

# Implementation Plan: [Feature/Project Name]

## Overview
[One paragraph summary of what we're building]

## Architecture Decisions
- [Key decision 1 and rationale]
- [Key decision 2 and rationale]

## Task List

### Phase 1: Foundation
- [ ] Task 1: ...
- [ ] Task 2: ...

### Checkpoint: Foundation
- [ ] Tests pass, builds clean

### Phase 2: Core Features
- [ ] Task 3: ...
- [ ] Task 4: ...

### Checkpoint: Core Features
- [ ] End-to-end flow works

### Phase 3: Polish
- [ ] Task 5: ...
- [ ] Task 6: ...

### Checkpoint: Complete
- [ ] All acceptance criteria met
- [ ] Ready for review

## Risks and Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | [High/Med/Low] | [Strategy] |

## Open Questions
- [Question needing human input]