generar-backlog

PRD + Tech Design → 待办事项拆解器

目标

将已批准的 PRD.md 和 TECH-DESIGN.md（及其 ADR）转化为一份有序的可实施规格清单——填补「我有产品和架构」与「我知道该先做什么」之间的空白。每个待办事项的范围都应恰到好处，能够成为一个独立的 SDD 变更（一次 sdd-new/规格驱动周期），既不是整个功能领域，也不是单个按钮。

此技能不会运行 SDD 本身，也不会编写代码——它只会生成地图，供 SDD 周期逐项使用。

必需输入

• PRD.md — 必需。
• TECH-DESIGN.md 及其 adrs/*.md — 必需。缺少架构进行拆解，会导致待办事项不符合组件边界。

如果缺少其中任一项，请停止并索取。

工作流

1. 完整阅读 PRD.md 和 TECH-DESIGN.md（以及 ADR）。
2. 根据两份文档已确立的内容，识别自然的实施单元：PRD 中的流程和验收标准，以及 TDD 中的组件／数据边界。不要引入无法追溯到这两份文档之一的范围。
3. 将每个单元的规模控制在实际可由一个 SDD 周期完成的范围：足够大，能形成有价值且完整的切片；又足够小，能完成规格编写、设计和实施，而不会变成一个小型项目。名为「整个系统」的待办事项太大；名为「更改一个按钮的颜色」的待办事项又太小——遇到任一极端时都应标记出来，而不是默默接受。
4. 按依赖关系而非猜测的优先级排列待办事项：其他事项所依赖的事项（例如，任何使用数据模型或身份验证的功能，都要先完成数据模型或身份验证）应排在前面，无论它们看起来多么有趣。
5. 对每个事项，标记其是否可能需要作为上下文提供的领域专属业务规则——判断依据：该事项涉及专业计算、受监管的逻辑，或超出通用 PRD/TDD 定义范围的术语（例如，会计模块的会计科目表规则）。不要假设每个项目都有此类需求——大多数项目都没有。若需要，请明确注明：「在为此事项生成 spec 之前，请分享该领域的业务规则文档（如有），作为上下文。」——此技能不会生成或索取这些文档本身，只会标记它们在哪些地方会起作用。
6. 定稿前先向用户展示待办事项草案。明确询问：顺序是否合理？是否有事项需要拆分或合并？对于已标记的事项，是否已有应在此处注明的领域规则文档？收到答复后再写入文件。
7. 在项目根目录写入 BACKLOG.md。

输出格式（BACKLOG.md）

# Backlog: {Nombre del proyecto}

| # | Item | Alcance | Depende de | Contexto extra requerido |
|---|---|---|---|---|
| 1 | {Nombre} | {1 línea} | — | — |
| 2 | {Nombre} | {1 línea} | #1 | Reglas de negocio de {dominio} |

## Cómo usar este backlog

Cada ítem es una spec independiente. Al implementarlo, arrancá un ciclo de Spec-Driven
Development (`sdd-new` o el flujo equivalente de tu harness) usando este ítem como el
"change" — no el proyecto completo. Si la columna "Contexto extra requerido" tiene algo,
compartilo como contexto al generar la spec de ese ítem.

质量关卡

返回前，静默检查：

• 每个待办事项都能追溯到 PRD 或 TDD 中的明确内容——没有凭空添加的内容。
• 没有事项的规模是「整个项目」或单个琐碎改动。
• 依赖关系无环，基础事项排在依赖它们的事项之前。
• 需要深入领域知识的事项已标记为需要额外上下文——既不默认为需要，也不默默遗漏。