开发任务

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

语言规则

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

触发条件

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

前置条件

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

运行模式

/devdocs-dev-tasks              → 标准模式（逐步确认）
/devdocs-dev-tasks --fast       → 跳过逐步确认，直接生成，仅最终确认

`--fast` 模式

使用合理默认值（不询问任务粒度偏好等）
仅保留最终写入前的 1 次确认
默认行为不变，--fast 是 opt-in

工作流程

读取文档：加载所有前置阶段文档
识别组件：将系统模块映射为任务
TDD 分层：对每个任务分类层级（🔴🟡🟢⚪），按任务分层规则标记
定义依赖：建立任务执行顺序
评估范围：确保任务粒度合适
生成任务文档：按层级分组输出，每个任务必须包含对应的 TDD 执行步骤：
- 🔴 核心逻辑：红→绿→重构三步（必须包含 TDD 执行步骤 区块）
- 🟡 接口层：红→绿两步（TDD 执行步骤（推荐） 区块）
- 🟢 UI 层：实现→验证→补测试（普通执行步骤）
- ⚪ 基础设施：实现→集成测试验证（普通执行步骤）
- 参照 templates/task-template.md 各层级示例
用户确认：获得批准
加载到 TodoWrite：可选，添加任务到追踪列表

上下文管理

分批原则

按功能点 (F-XXX) 分批设计任务，每批完成一个功能点的全部任务拆分。

质量锚点

首个功能点的任务列表作为质量锚点
每个新功能点开始前，回顾首批任务的详细程度（TAR 字段完整性、文件路径具体性、依赖关系明确性）
若当前批次详细程度明显低于锚点，立即补充

一致性自检

每个功能点的任务设计完成后，对比检查：

TAR 三字段是否与首批一致（无缺项）
文件路径是否具体到文件名（非"相关文件"等模糊描述）
任务粒度是否一致（无超过 4 小时的任务）

输出文件

主文件：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。

详见 templates/archive-rules.md

任务设计原则

每个任务必须满足 TAR 原则：

原则	说明	必需内容
可测试 (Testable)	可通过自动化或手动测试验证	测试方法和预期结果
可验收 (Acceptable)	有明确的验收标准	具体、可量化的完成标准
可审查 (Reviewable)	可独立进行代码审查	Review 要点

任务分层

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

层级	TDD 模式	说明
核心逻辑 (Service/Domain)	🔴 强制	测试先行
接口层 (Controller/API)	🟡 推荐	建议测试先行
UI 层 (Component/View)	🟢 可选	可实现后补
基础设施 (DB/Config)	⚪ 不适用	集成测试验证

约束

基础约束

单个任务必须在 4 小时内可完成
必须指定任务依赖
必须按依赖排序，不能有循环依赖
文件路径必须具体，不能写"相关文件"
必须提供依赖关系图
优先级：P0（阻塞）、P1（重要）、P2（次要）
任务编号格式：T-XX（顺序编号）
后批次任务详细程度不低于首批次（TAR 完整性、路径具体性、粒度一致性）
每个功能点完成后执行一致性自检

需求追溯约束

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

TAR 原则约束

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

分层约束

核心逻辑任务必须标记 🔴 并包含完整 TDD 执行步骤（红🔴→绿🟢→重构🔵）
接口层任务必须标记 🟡 并包含推荐 TDD 执行步骤（红🔴→绿🟢）
UI 层任务标记 🟢 可选 TDD，执行步骤为：实现→验证→补测试
基础设施任务标记 ⚪ 不适用 TDD，执行步骤为：实现→集成测试验证
任务文档必须按层级分组输出（基础设施→核心逻辑→接口层→UI 层）
每个任务的属性表必须包含 TDD 模式 行

执行约束

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

增量任务管理

来源

来源 Skill	触发场景	操作
`/devdocs-feature`	新增功能需求	追加任务到列表
`/devdocs-bugfix`	Bug 修复需求	插入高优先级任务
`/devdocs-insights`	改进建议确认	追加任务到列表

增量操作

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

完成后操作

用户确认任务文档后：

询问用户是否开始开发
如是，使用 TodoWrite 添加所有任务到追踪列表
建议从第一个任务开始，或使用批量模式：/devdocs-dev-workflow T-01~T-XX
执行任务时必须使用 /devdocs-dev-workflow
支持按功能点（F-XXX）或用户故事（US-XXX）批量执行

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

参考资料

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

子 Agent 摘要格式

当本 Skill 作为子 Agent 运行时，返回以下结构化摘要：

skill: devdocs-dev-tasks
tasks_created: X
task_range: "T-01~T-10"
layers:
  core: X      # 🔴
  api: X       # 🟡
  ui: X        # 🟢
  infra: X     # ⚪
status: completed
output_files:
  - docs/devdocs/04-dev-tasks.md

下一步

完成后建议使用 /devdocs-dev-workflow 执行开发任务。

提示：文档变更较大时，建议运行 /agent-memory 同步记忆文件。

协作 Skill

场景	Skill
执行开发任务	`/devdocs-dev-workflow`
同步文档状态	`/devdocs-sync`
新增功能需求	`/devdocs-feature`
修复 Bug	`/devdocs-bugfix`

devdocs-dev-tasks