用途
SDD 工作分解用于把一份经过评审、批准的规格说明（specification）翻译成可执行的任务序列，并附带显式依赖关系、每个任务的验收标准，以及面向实现智能体的集成指令。
它在 SDD 流水线中的位置为：
SPECIFY → [PLAN] → TASKS → IMPLEMENT → VERIFY
该技能处于 PLAN 阶段，负责弥合「要构建什么」（规格）与「如何以独立、可验证的单元来构建」之间的差距。它同时产出人类可读的任务计划，以及驱动实现智能体的 CLAUDE.md / AGENTS.md 内容。
核心原则：规格即计划
该技能不会从零发明计划，而是从规格中提取计划。规格已经定义了系统必须表现的行为——每个行为映射到一个任务。每个任务都可追溯到 SPEC.md 的特定章节。计划中不存在规格未要求的工作，规格中也不存在未被至少一个任务覆盖的需求。
这正是 SDD 分解与通用项目规划的区别所在。规划者不问「需要做哪些工作？」——规格已经回答了这个问题。规划者问的是「我们如何为安全执行而排序和打包这些工作？」
主要能力：产物金字塔输出 TASK-PLAN.md
任务计划遵循产物金字塔结构：
- L1：阶段总览——任务总数、关键路径估算、关键依赖、推荐执行顺序，文件为 00-index.md（入口点）。
- L2：按阶段或功能区域划分的任务组——依赖图、由规格章节派生的每组验收标准，文件为各个 *.phase.md。
- L3：单个任务卡——每个都带有由规格派生的验收标准、估算复杂度、前置条件、CLAUDE.md 指令，位于 tasks/ 目录。
- SOURCES：每个任务到其所实现的 SPEC.md 章节的交叉引用，位于每个文件的页脚。
使用方式
加载指引
参考资料：
- 任务分解方法论（references/task-decomposition-methodology.md）：在编写任何任务计划之前加载——用于规格到任务提取、规模划分、原子性的模式。
- 依赖映射（references/dependency-mapping.md）：用真实约束对任务排序——由规格派生的依赖链，而非猜测。
- CLAUDE.md 作为规格层（references/claude-dot-md-as-spec-layer.md）：在产出任务计划之后——为实现智能体生成 CLAUDE.md 指令。
模板：
- TASK-PLAN.md（templates/TASK-PLAN.md）：从已评审规格产出完整任务计划时使用。
脚本：
- spec-to-tasks.sh（scripts/spec-to-tasks.sh）：在编写完 TASK-PLAN.md 之后运行——校验每条规格需求都有覆盖它的任务。
触发条件
在以下情况调用该技能：
- 一份已评审、批准的规格需要被拆分为可执行任务；
- 现有任务计划需要重构，因为新发现的依赖使原有排序失效；
- 存在多份规格用于一次协同发布，需要跨规格的依赖解析；
- 实现智能体需要一份由规格和任务计划生成的 CLAUDE.md 或 AGENTS.md。
分解规则
- 原子性：每个任务必须可独立实现和验证。检验标准是：如果一个任务完成了，但其验收标准要等另一个任务也完成才能检查，那么这些任务就不是原子的——应合并它们或重新定义边界。
- 规格可追溯性：每个任务正文必须包含 Spec: -- section X 引用，指回定义其需求的 SPEC.md 章节。这不是可选元数据，而是防止实现过程中范围漂移的机制。
- 任务规模：任何任务都不应超过一个实现工作会话（对 AI 编码智能体而言通常为 30-120 分钟，视复杂度而定）。超过此规模意味着规格章节过于粗糙，需要细化。应先进一步分解规格章节，再分解任务。
- 依赖诚实：只记录真实的、由规格派生的依赖。当任务 B 需要任务 A 的输出（函数签名、数据结构、模式、模块接口）且 B 无法打桩或模拟时，依赖才是真实的。可由契约或接口定义满足的依赖不是真实依赖——应在规格中定义该契约。
CLAUDE.md 交接
任务计划完成后，该技能会生成实现智能体所读取的 CLAUDE.md 指令。这些指令包括：
- 应加载哪些 SPEC.md 章节和任务计划文件；
- 执行顺序与依赖约束；
- 验证所期望的验收标准格式；
- 针对规格歧义的升级协议。
适用场景
适用于已评审规格到可执行任务的转换、因依赖变化而重构任务计划、多规格协同发布的跨规格依赖解析，以及为实现智能体生成 CLAUDE.md / AGENTS.md。
限制
资料未提供关于收费、价格、平台支持范围或具体效果的信息。