用途：在 Spec Loop 的任务文件路径上做工作分解（work breakdown），是在 planning-form 选择确定为「带子任务的任务文件」或多个任务文件/待办项之后使用的规划伴侣技能，不替代 planning-form 选择、澄清、任务文件规则或审批门。
主要能力与用法：为拆分出的每个（子）任务撰写标题、必要的标识/状态元数据以及 Scope、Motivation，必要时加入已明确且实质相关的 Constraints；按交付成果而非技术层命名；新建待办任务文件用可读的三位数字前缀，且前缀在所属文件夹内本地有效。对实现类（子）任务要求可独立发布（releasable），特征实现优先切成可发布的垂直切片；尽量让最早的任务呈现可见可执行行为（fast-payoff），推迟 setup、生成、存储、编排与泛化。跨层工作放进同一（子）任务；独立重构单独成子任务，是否使用独立任务文件取决于是否需要独立发布决策；支撑性文档、术语表、配置、迁移与测试与所支持行为放在同一（子）任务，除非它们是独立交付物。
限制：在整体工作的 Scope 与 Motivation 清晰前不得起草或修订分解；需要澄清时先用 spec-loop-clarify-task。不要用工作分解去发现或决定只影响后续 Design/Test 的 Constraints；若未知约束影响（子）任务边界、顺序、可发布性或连贯性，则视为阻塞项。不要在分解阶段新写 Briefing、Research、Scenario、Glossary、Analysis、Design、Test specification，也不要创建 Findings 或 Implementation notes。默认禁止不可独立发布的实现（子）任务（仅脚手架、仅 setup、仅模型、仅逻辑、仅 API、仅持久化、仅 UI、仅测试、仅文档等），除非用户明确选择退出并在该（子）任务 Scope 中记录。不得为不清晰的未来工作创建占位实现（子）任务。若出现阻塞性未知，按规则路由澄清、ADR 或研究/探针/原型/目录/证明类（子）任务；不要创建依赖未知结果的下游实现（子）任务。chat-only/无文件规划需先升级到任务文件路径，因为对话内容不是持久的项目状态。任务文件过大或转换形态时可用 spec-loop-compact-task-file 后再继续。保存前需做自检，确认各（子）任务可独立评审、实现类（子）任务带自身自动化测试且其后继未实现时状态仍然连贯可发布等。分类：编程与开发。