开发任务

将系统设计分解为可执行、可追踪的开发任务。

语言规则

• 支持中英文提问
• 统一中文回复
• 使用中文生成文档

触发条件

• 用户已完成系统设计和测试用例
• 用户要求拆分开发任务
• 用户需要迭代/Sprint 规划
• 来自 /devdocs-feature、/devdocs-bugfix、/devdocs-insights 的增量需求

前置条件

• 需求文档：docs/devdocs/01-requirements.md
• 系统设计文档：docs/devdocs/02-system-design.md
• 测试用例文档：docs/devdocs/03-test-cases.md
• 如不存在，建议先运行前置阶段

工作流程

1. 读取文档：加载所有前置阶段文档
2. 识别组件：将系统模块映射为任务
3. 定义依赖：建立任务执行顺序
4. 评估范围：确保任务粒度合适
5. 创建任务列表：生成结构化任务文档
6. 用户确认：获得批准
7. 加载到 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 原则：

任务分层

根据任务类型分层，决定 TDD 模式：

约束

基础约束

• 单个任务必须在 4 小时内可完成
• 必须指定任务依赖
• 必须按依赖排序，不能有循环依赖
• 文件路径必须具体，不能写”相关文件”
• 必须提供依赖关系图
• 优先级：P0（阻塞）、P1（重要）、P2（次要）
• 任务编号格式：T-XX（顺序编号）

需求追溯约束

• 每个任务必须关联功能点 (F-XXX) 和验收标准 (AC-XXX)
• 每个任务必须关联测试用例 (UT/IT/E2E-XXX)
• 测试用例来自 03-test-*.md 文档

TAR 原则约束

• 每个任务必须包含测试方法（如何验证）
• 每个任务必须包含验收标准（可量化的完成标准）
• 每个任务必须包含 Review 要点（代码审查关注点）
• 测试方法必须可执行（不能是模糊描述）
• 验收标准必须可量化
• Review 要点必须针对任务类型

分层约束

• 核心逻辑任务必须标记 🔴 强制 TDD
• 接口层任务标记 🟡 推荐 TDD
• UI 层任务标记 🟢 可选 TDD
• 基础设施任务标记 ⚪ 不适用 TDD

执行约束

• 任务执行必须使用 /devdocs-dev-workflow
• 禁止跳过 dev-workflow 直接写代码（会导致追溯失效）
• 任务完成后必须执行 /devdocs-sync --trace

增量任务管理

来源

增量操作

• 新增任务：追加到任务列表末尾，重新编号
• 插入任务：高优先级任务插入合适位置
• 更新依赖：调整受影响任务的依赖关系
• 更新状态：标记任务完成/进行中

完成后操作

用户确认任务文档后：

1. 询问用户是否开始开发
2. 如是，使用 TodoWrite 添加所有任务到追踪列表
3. 建议从第一个任务（T-01）开始
4. 执行任务时必须使用 /devdocs-dev-workflow

重要：直接写代码而不使用 dev-workflow 会导致代码缺失 @satisfies/@verifies 标注， 使 /devdocs-sync --trace 无法自动追溯，破坏文档↔代码的闭环。

参考资料

• task-template.md – 完整任务文档模板
• archive-rules.md – 任务归档规则

协作 Skill