该技能的目标是把已批准的 PRD.md 与 TECH-DESIGN.md（连同其 ADR）转化为一个有序、可实施的规格待办列表，填补“我有产品和架构”与“我知道先构建什么”之间的空白。每个待办项的范围应能被限定为一次 SDD 变更（一个 sdd-new / spec-driven 循环），既不是一个完整功能领域，也不是单个按钮。该技能本身不运行 SDD，也不编写代码——它产出的是 SDD 循环将逐项消费的路线图。
必需输入：PRD.md 为必需；TECH-DESIGN.md 及其 adrs/*.md 为必需。缺少架构的拆解会产生不尊重组件边界的待办项。若任一缺失，应停止并索要。
工作流：完整阅读 PRD.md 与 TECH-DESIGN.md（及 ADR）；从两份文档已确立的内容中识别自然实施单元——PRD 中的流程与验收标准、TDD 中的组件与数据边界，不虚构无法追溯到这两份文档的范围；将每个单元的大小设定为现实中一次 SDD 循环可完成：大到足以构成连贯的价值切片，小到无需成为独立迷你项目即可被规格化、设计和实现，标题为“系统”的待办项过大、标题为“更改按钮颜色”的待办项过小，遇到任一极端应标记而非默默接受；按依赖而非猜测的优先级排序，被其他项依赖的项（如数据模型或认证先于任何使用它们的内容）应排在最前，无论其多有趣；对每个项标记其是否可能需要领域特定业务规则作为上下文，启发式判断：该项涉及超出通用 PRD/TDD 所定义的专业计算、受监管逻辑或术语（例如会计模块的会计科目表规则），不要假设每个项目都有——大多数没有，当标记时明确注明“在生成该项的规格之前，如有该领域的业务规则文档，请作为上下文分享”，该技能本身不生成也不索要该文档，只标记其重要之处；在最终确定前向用户展示草稿待办列表，明确询问顺序是否合理、是否有项需要拆分或合并、对于被标记的项是否已有应在此注明的领域规则，等待回答后再写入文件；在项目根目录写入 BACKLOG.md。
输出格式（BACKLOG.md）：标题为“# Backlog: {项目名称}”，随后是一个表格，列为 #、Item、Alcance、Depende de、Contexto extra requerido，示例行如“| 1 | {名称} | {1 行} | — | — |”和“| 2 | {名称} | {1 行} | #1 | {领域}的业务规则 |”。之后是“## 如何使用此 backlog”一节，说明每个项是一个独立规格，实施时以该项作为“change”启动 Spec-Driven Development 循环（sdd-new 或你的 harness 的等效流程），而非整个项目；若“Contexto extra requerido”列有内容，在生成该项规格时将其作为上下文分享。
质量门：返回前静默检查——每个待办项都可追溯到 PRD 或 TDD 中的明确内容，没有虚构；没有项被设定为“整个项目”或单个琐碎变更；依赖无环且基础项先于依赖它们的项；领域密集型项被标记需要额外上下文，既不默默假设需要，也不默默跳过。