用途：在写代码前把方案想清楚，产出另一模型（或较弱模型）无需重新推导即可执行的计划，并在看到任何结果之前固定成功标准。
主要能力：按风险而非工作量选择档位。难以回退、涉及隐私或认证、数据外发、公共契约、战略转向的改动使用重型档：完整计划文档，执行前设用户批准门（条件允许时用 plan mode）。已知的工程 backlog 用轻量档：由带完整规格的跟踪 issue 承载，不另写计划文档。单次普通改动不写正式计划，直接沿用工程循环的步骤顺序。
重型计划必备章节：标题与 issue 编号、背景（含数据的证据）、可复用且不得重建的既有文件与函数、方案及为何不选主要替代方案的一段说明、文件路径、决策门（在看结果之前设定明确的通过/失败标准，失败则给出诚实结论与具名回退方案）、仅限人工完成的前置事项、子代理预算上限、被单方面解决的开放判断点清单、验证方式（命令、阈值、执行者；保持行为的重构须先取原始代码的 pin/特征测试）。轻量档则把 issue 本身当作计划，含症状、根因（file:line 与证明的测试或提交）、具体修改与政策行、引用。
必要用法要点：提出计划前先列出 3-5 个若为假就会推翻计划的事实，并逐一直查原始来源或实时状态；成功阈值须在实验或实现前预先登记，不得在原始门失败且未披露的情况下调参重跑；检查同跟踪器中未关闭 issue、ADR 与计划文件是否含有额外约束；先查可复用项再提新模块；需要用户决定的事项（难回退、对外引用、花费资金或大量算力）合并为一个结构化问题，给出 2-4 个带标签选项、其中一项标“(Recommended)”并附一行基于证据的理由，超时未答则按推荐项推进并披露；内部实现细节自行决定；计划需持久化到聊天之外（GitHub epic/issue 加可度量的 Definition of Done），优先用严格预期失败测试自我约束；新信息若推翻或门控已决策事项，先停下下游工作解决上游决策并说明次序变化原因；来自子代理的计划须逐条核验引用的 file:line 与其开放判断点后才采纳，宏观架构由最高档模型负责，架构批准后才可由中档模型展开有界阶段；门失败时执行具名回退，回退原型代码（需授权），并在跟踪器与草稿中记录死路（试过什么、代价、失败原因），被推迟的想法显式标记而非默默丢弃。
阶段划分：一个阶段等于一个可独立评审与测试的 PR，约一个子系统、一次迁移或不超过约 500 行非生成净变更；含两个以上此类单元则为 epic，否则为单一 feature；阶段名用 2-3 个词的 kebab-case，去掉停用词且对象名词在前，如 backend-metrics、sync-engine。
限制：资料未提供支持的平台、安装方式、收费情况与实际效果数据；文中提及的具体模型名称（如 Sol、Fable、Opus、Terra、Luna、Sonnet）属来源上下文描述，具体可用性以实际环境为准，资料未进一步说明。