写完功能 spec 后，把需求拆成按依赖排序的任务波次…

在功能 spec 写完之后、开始编码之前，把特性拆成大小合适、依赖有序的波次与任务，便于并行推进并随时看到实现进度。

适用场景

解决思路

1. 阅读 spec：从 agent plan 或 gjalla spec 中找出所有行为需求和技术改动。
2. 识别任务：每个任务只涉及 1-2 个文件，产出小而可评审的 diff，并且可被验证。
3. 梳理依赖：确定哪些任务必须先完成，其他任务才能开始。
4. 划分波次：同一波次内的任务可并行执行，波次之间按顺序串行推进。
5. 按统一格式书写每个任务：ID（如 W1-T1、W1-T2、W2-T1）、Description（一行说明改什么）、Files（将被修改或创建的精确文件路径）、Depends On（依赖的任务 ID，同波次内则为 none）、Acceptance（如何验证该任务已完成）。
6. 用波次把任务归入逻辑/模块化的区块，排出直观顺序；例如数据模型改动通常要放在最前面，为后续波次打好基础。
7. 在波次和任务上留出标记完成的位置，以便实现过程中一眼看出当前状态。
8. 确保拆解中包含文档、验证、测试等工作，不要遗漏。
9. 控制单个 spec 的任务总数在 20 个以内以免过载；更大的特性拆成多个 spec。
10. 把拆解结果写在 spec 目录中、与设计文档放在一起，让人（或压缩后恢复的会话）无需重读任何东西就能看清实现进度。
11. 每完成一个波次就在该文件中勾掉，并在旁边附上验收证据。
12. 最后一个波次验证通过后，把改动移入 review（参见 gjalla-code-review）。

适用边界 · 注意事项

• 还没有写出 spec 或 agent plan 时——本技能的前提是先有 spec 可读。
• 特性过大、任务数会明显超过 20 个时，应先拆成多个 spec，而不是硬塞进一次拆解。
• 改动极小、无需并行与进度追踪的零散任务，单独做波次拆分收益不大。