任务拆解与规划

要解决的问题

当 Agent 接到一个规格需求时，最常见的失败方式不是「能力不够」，而是直接开工后在一团混乱里返工：任务边界含糊、验收标准缺失、依赖关系没有被显式记录，等到上下文窗口被撑爆才发现漏了关键环节。尤其当多个 Agent 或多个会话并行推进时，没有书面计划就意味着没人知道谁该先动手、什么时候该停下来验证。

这个技能把规划本身当作一等任务，强制在写任何代码之前先产出两份可检查的产物：tasks/plan.md 和 tasks/todo.md。

核心能力与工作流程

进入只读规划模式。 在动手之前，先读规格和相关代码段，识别既有模式与约定，梳理组件之间的依赖关系，记录风险与未知项。这一阶段明确禁止写代码，输出只有计划文档和任务清单。

绘制依赖图，按底层优先排序。 先建基础再往上叠，实现顺序跟随依赖图自底向上，避免后面每一步都被前一步卡住。

垂直切片，而非水平切片。 不是先做完全部数据库、再做完全部 API、最后做 UI，而是一次打通一条完整的功能路径。每条垂直切片都能独立运行、独立测试。

任务结构化与排序检查点。 每个任务都带验收标准和验证步骤，每 2-3 个任务插入一个显式检查点，高风险任务尽量前置以便快速失败，每个任务结束时系统都处于可用状态。

明确并行边界。 独立功能切片和测试可以安全并行；数据库迁移、共享状态变更、依赖链必须串行；共享 API 契约的功能先定契约再并行。

适用边界与注意点

任务规模按文件数划分：XS 到 M 是 Agent 的舒适区（约 1-5 个文件）；L（5-8 个文件）应进一步拆分；XL 直接视为不合理。需要继续拆的信号包括：预计超过一个专注会话、验收标准写不满 3 条要点、跨越两个以上独立子系统、任务标题里出现「和」字。

什么时候不该用： 单文件改动且范围显而易见，或规格本身已经包含定义清晰的任务时，这套流程反而是负担。

开始实现前的核对清单： 每个任务都有验收标准与验证步骤；依赖已识别并正确排序；没有任务超过约 5 个文件；主要阶段之间存在检查点；人类已经审阅并批准计划。记住一个反直觉的事实：10 分钟的规划能省下数小时的返工，而「边做边想」正是产生混乱的根源。