用途：plan-builder 根据目标描述与上下文，生成按依赖排序、按并行波次分组的可执行 markdown 计划，供 plan-runner 执行。适用于已有明确目标（功能、迁移、重构、清理）并需在动手前拆分为有序工作项的场景；不负责需求收集，目标含糊时应先用 interview-me 澄清。
主要能力与步骤：一、读取上下文：架构文档（如 ARCHITECTURE.md、相关 CLAUDE.md）、受影响区域现有代码、访谈输出或规格，识别现状、待改内容与固定/可变边界。二、选择方案：若只有一条自然路径，简要说明后继续；若存在多条可行路径，直接分析并产出符合 references/alternatives-schema.md 的 AlternativesOutput（含 Alternative[]），给出具体文件、函数、模式、诚实的置信度与真实权衡，再用 AskUserQuestion 让用户选择，未选定不进入下一步。三、结构大纲：产出技术设计，分离架构决策（类型、schema、签名）与执行顺序，可含 DB schema 变更、API 端点签名、组件树、类型定义；不含实现逻辑、波次顺序与测试策略，需用户批准。四、识别工作项：拆成原子项，每项约一次提交，自包含、可验证。五、依赖排序与波次分组：无依赖且无文件重叠者同波次并行；有依赖者后置；同文件被多项修改则串行；每波次最多 3 项（对应 plan-runner 子智能体并发上限）；优先少而厚的波次。检查点要求用户批准后再写文件。六、写入计划：输出到 meta/workflows/plans/plan-NNN-<topic-slug>.md，目录不存在则创建，取最大编号加 1（空目录从 001 开始），并告知路径。
计划文件结构：标题、Goal、Criteria、Created、Constraints、Approach（仅多路径时）、Structure Outline、按 Wave 分组的复选框条目、Out of scope。条目用稳定 ID（T1、T2…）而非序号位置，依赖以 ID 引用，每项须写明涉及文件。需在顶部保留 criteria/constraints 元数据供下游 review 与 fix-verify-loop 使用。计划不含 review、测试、验证步骤，这些由 two-pass-review、fix-verify-loop 处理，计划项仅为实现工作。超过约 15 项时拆为父路线图加子计划。
限制：目标含糊或缺约束时应停止并先澄清；未获用户方案选择、结构批准与条目批准前不继续；波次分组须遵守其五条规则。