用途
Milestone Planning（Ultraplan）用于把复杂、多日任务拆解为优化后的里程碑。它的核心判断是：里程碑是长周期执行的基本单位，一个糟糕的里程碑拆解会连锁导致数天浪费的工作。为避免这种情况，该技能依赖两个机制：一是“扎根”，即草稿必须建立在并行探索所收集的真实代码库证据之上，而不是对代码可能长什么样的假设；二是“对抗压力”，即由独立评审员在真正执行之前、以低成本方式攻击草稿。
主要能力
该技能把拆解过程组织为多个阶段：
- 问题框定与广泛探索：识别目标、范围边界、技术约束和成功标准，并派出多个只读 Explore 子代理并行探索，每个代理有不同视角，包括架构与接口、依赖与数据流、验证环境、约定与历史，以及按任务需要追加的特定视角（如数据工作的 schema/迁移视角、安全相关工作的认证/权限视角、API 变更的客户端兼容视角）。探索结果汇总为自包含的 Problem Brief，包含目标、范围、技术上下文、探索摘要、约束、成功标准和验证策略。
- 草稿拆解：并行派出两个起草代理，分别采用不同组织原则——Skeleton A 接口优先，先定义契约与接口再定义消费者；Skeleton B 风险优先，最早处理风险最高的集成和最模糊的需求。主代理比较两个骨架，选择更强的一个并嫁接另一个的优越元素，形成 DRAFT v1。每个里程碑必须写明名称、目标、可二元判定的成功标准、依赖、受影响文件、风险/工作量/用户价值/中止点，以及证据（哪些探索摘要发现支持该边界）。证据字段为空的里程碑被视为猜测。
- 对抗性评审小组：对草稿派出评审小组，所有评审员在同一消息中并发运行。核心评审员固定为 4 个：隐藏复杂性评审员攻击工作量估计；依赖与排序评审员攻击 DAG；可验证性评审员攻击成功标准；集成与风险评审员攻击排序。另可按问题性质追加最多 2 个特定评审员，如价值与排序、迁移与兼容、安全与访问、性能。评审员必须给出具体发现，标注严重程度（Structural、Blocking、Concern、Nit），并给出最小修复。
- 修订循环（Critique Until Dry）：每条发现逐字记录在 Critique Resolution Log 中，标记为接受（说明草稿如何修改）或拒绝（附有证据支持的理由）。接受修复后，若本轮产生任何 Structural 或 Blocking 发现，则对修订后的草稿派出全新评审轮次。只有当完整一轮产生零个新的 Structural 或 Blocking 发现时，草稿才被锁定。最多 3 轮；第 3 轮后仍有争议的 Blocking 发现会连同双方陈述升级给用户。
- 集成验证里程碑：草稿锁定后，主代理自动在 DAG 末尾追加一个集成验证里程碑，作为结构性保证，评审员无权否决其存在。
- 独立 DAG 验证：追加集成验证里程碑后，主代理独立验证完整 DAG 结构，包括循环依赖检查、并行里程碑的文件冲突检查、孤儿检查、以及每个里程碑至少 2 个可二元判定成功标准的检查。
- 用户评审与锁定：这是整个长周期流程中唯一的审批关口。推荐里程碑数量为 3-7 个；超过 7 个会警告，超过 10 个需要用户明确批准。用户批准后，所有产物保存到 harness 状态目录。
使用方式
该技能需要清晰的问题陈述作为输入，可以来自 clarification 技能产出的 Context Brief 文件（首选），或来自用户直接、详细的请求（必须包含目标、范围、约束）。如果输入模糊，应先回到 clarification 技能。当用户提出复杂多日任务、长周期 harness 需要里程碑拆解、用户说出“plan milestones”“break this into milestones”或“ultraplan”、或任务明显需要多个独立实现阶段时使用。
适用场景
适用于复杂、多日、需要多个独立实现阶段的任务，以及需要为长周期执行做里程碑拆解的场景。
限制
不适用于单日任务（应直接使用 plan-crafting）、少于约 8 个实现步骤的任务、里程碑已定义且用户想要执行的场景（应使用 long-run）、以及工作范围仍不明确的情况（应先使用 clarification）。此外，硬性门槛要求：起草前必须探索；每轮所有评审员必须并行运行；每个评审员必须收到完整 Problem Brief 和完整草稿；评审员之间不得看到彼此的评审意见；每条评审意见必须显式解决；每个里程碑必须有可二元判定的成功标准；里程碑依赖必须构成 DAG；不得为琐碎任务生成里程碑。