开发任务
将系统设计分解为可执行、可追踪的开发任务。
语言规则
触发条件
- 用户已完成系统设计和测试用例
- 用户要求拆分开发任务
- 用户需要迭代/Sprint 规划
- 来自
/devdocs-feature、/devdocs-bugfix、/devdocs-insights 的增量需求
前置条件
- 需求文档：
docs/devdocs/01-requirements.md
- 系统设计文档：
docs/devdocs/02-system-design.md
- 测试用例文档：
docs/devdocs/03-test-cases.md
- 如不存在，建议先运行前置阶段
工作流程
- 读取文档：加载所有前置阶段文档
- 识别组件：将系统模块映射为任务
- 定义依赖：建立任务执行顺序
- 评估范围：确保任务粒度合适
- 创建任务列表：生成结构化任务文档
- 用户确认：获得批准
- 加载到 TodoWrite：可选，添加任务到追踪列表
输出文件
主文件：docs/devdocs/04-dev-tasks.md
文档拆分规则
当满足以下条件时，应拆分文档：
- 任务数量超过 20 个
- 文档超过 300 行
- 涉及多个独立模块
拆分方式：
docs/devdocs/
├── 04-dev-tasks.md # 主文档：任务概览、依赖图、执行检查清单
├── 04-dev-tasks-infra.md # 基础设施任务
├── 04-dev-tasks-core.md # 核心逻辑任务
├── 04-dev-tasks-api.md # 接口层任务
└── 04-dev-tasks-test.md # 测试任务
任务归档
已完成任务过多时归档到 04-dev-tasks-archive.md。
详见 archive-rules.md
任务设计原则
每个任务必须满足 TAR 原则：
| 原则 |
说明 |
必需内容 |
| 可测试 (Testable) |
可通过自动化或手动测试验证 |
测试方法和预期结果 |
| 可验收 (Acceptable) |
有明确的验收标准 |
具体、可量化的完成标准 |
| 可审查 (Reviewable) |
可独立进行代码审查 |
Review 要点 |
任务分层
根据任务类型分层，决定 TDD 模式：
| 层级 |
TDD 模式 |
说明 |
| 核心逻辑 (Service/Domain) |
🔴 强制 |
测试先行 |
| 接口层 (Controller/API) |
🟡 推荐 |
建议测试先行 |
| UI 层 (Component/View) |
🟢 可选 |
可实现后补 |
| 基础设施 (DB/Config) |
⚪ 不适用 |
集成测试验证 |
约束
基础约束
需求追溯约束
TAR 原则约束
分层约束
执行约束
增量任务管理
来源
| 来源 Skill |
触发场景 |
操作 |
/devdocs-feature |
新增功能需求 |
追加任务到列表 |
/devdocs-bugfix |
Bug 修复需求 |
插入高优先级任务 |
/devdocs-insights |
改进建议确认 |
追加任务到列表 |
增量操作
- 新增任务：追加到任务列表末尾，重新编号
- 插入任务：高优先级任务插入合适位置
- 更新依赖：调整受影响任务的依赖关系
- 更新状态：标记任务完成/进行中
完成后操作
用户确认任务文档后：
- 询问用户是否开始开发
- 如是，使用 TodoWrite 添加所有任务到追踪列表
- 建议从第一个任务（T-01）开始
- 执行任务时必须使用
/devdocs-dev-workflow
重要：直接写代码而不使用 dev-workflow 会导致代码缺失 @satisfies/@verifies 标注，
使 /devdocs-sync --trace 无法自动追溯，破坏文档↔代码的闭环。
参考资料
协作 Skill
| 场景 |
Skill |
| 执行开发任务 |
/devdocs-dev-workflow |
| 同步文档状态 |
/devdocs-sync |
| 新增功能需求 |
/devdocs-feature |
| 修复 Bug |
/devdocs-bugfix |
