用途
Super Plan 是一个规划类技能，用于创建实施计划。在该技能激活期间，只做规划，不实现代码，除非用户明确改变任务。
适用场景：
- 任务足够复杂，适合分阶段执行
- 工作跨越多个文件、系统或决策点
- 用户要求计划、路线图、任务拆解或实施策略
- 变更包含重构、迁移、架构更新或高风险编辑
- 希望未来的执行者能以最少额外上下文逐阶段完成工作
不适用于极小的单步变更，除非用户明确想要一份书面计划。
主要能力
- 只规划，不会从规划静默切换到实现
- 以可重复的“信息收集 → 调研 → 澄清”循环为核心
- 先探索再设计阶段，计划基于真实仓库而非猜测
- 在信息收集阶段询问计划的技术细节程度和用户偏好的反馈频率，并在整个流程中遵循
- 按请求的频率提出聚焦的澄清问题；但“最少反馈”不会压制为避免不安全或实质性不同计划所必需的决策
- 当允许的子代理能力可用时，在循环中至少使用一个子代理执行有边界的只读调研任务
- 委派工作仅作参考；主规划者负责用户交互、综合、范围与架构决策、阶段设计、草稿、审批以及唯一的计划文件写入
- 将工作拆分为均衡、有意义、可审查且可独立执行的阶段
- 优先产出可交接的计划：每个阶段包含足够上下文，供另一个代理或人类执行
- 在用户审阅并明确批准草稿之前，不写入计划文件
- 保持技能与运行环境无关，使用通用能力描述而非特定产品工具名
- 写入计划后，进行总结，除非被要求，否则不把整个文件粘贴回对话
使用方式
信息收集 → 调研 → 澄清循环
重复该循环直到满足停止条件。
1. 信息收集
维护一份紧凑的工作简报，包含：预期结果、范围内与范围外工作、约束/优先级/成功标准、已提供上下文与已知仓库区域、假设与重要未知项、可能的系统/集成点/风险区域。不要重复询问已提供的信息。
首次信息收集时，尽量在一次交互中收集两项规划偏好：
技术细节：
- 简洁——最少文字，仅要点，跳过可选章节
- 标准——均衡细节，填写适用章节
- 详细——完整上下文、理由与边界情况说明
反馈频率：
- 最少——只询问会实质性改变计划的决策，否则使用合理默认值
- 标准——在最终确定前确认关键决策与假设
- 高——对大多数规划决策进行确认，并逐阶段确认方向
若无法获得偏好，默认使用标准细节与标准反馈。
同时在信息收集阶段选择计划目标位置：
- 仓库根目录的 PLAN.md
- plans/<task-name>.md，用于组织多计划工作流
对于 plans/，生成 kebab-case 文件名并允许用户调整。
首次循环迭代开始时，检查子代理能力是否可用，并在委派前查看其角色。将每次澄清回复视为下一次迭代的新信息收集。
2. 调研
在询问用户之前，先从证据中解决当前未知项。检查相关文件、结构、架构边界、约定、依赖、集成点、风险、测试与文档。追踪现有行为与执行顺序，足以支持阶段设计。检测仓库是否使用版本控制，以及检查点指导是否会实质性影响执行。当外部 API、标准、版本、限制、迁移路径或生态事实可能实质性改变计划时，使用当前外部来源。优先采用观察到的仓库事实与一手来源，而非假设。
当子代理能力可用时：
- 在整个循环中至少委派一个有边界的只读调研任务
- 当有助于覆盖或置信度时，划分独立的仓库区域或外部问题
- 若没有仓库或外部调研可做，则委派一个有边界的审查，寻找歧义、缺失约束、风险或候选澄清问题
- 仅在后续迭代中，当澄清引入可有用分离的独立调研时，才委派额外任务
- 要求提供发现、证据引用（如有）、不确定性、风险与规划影响
- 不允许子代理与用户沟通、选择最终范围或架构、设计阶段、撰写计划、批准假设、修改项目文件或实现任务
- 主规划者必须将委派发现与直接观察到的证据进行核对，并在依赖前解决冲突
3. 澄清
基于信息收集与调研，提出一轮聚焦、分组的问题。只询问用户最适合做出的决策。不要询问已提供材料、仓库检查或外部调研能回答的问题。当答案会实质性影响范围、架构、排序、风险、兼容性、发布、受影响系统或验证时，才提问。若版本控制检查点指导相关，询问用户偏好哪种工作流策略。在权衡已明确时，使用具体选项与建议。遵循请求的反馈频率。若没有实质性问题，不要仅为完成此步骤而打断用户；评估停止条件。每次回答后，返回信息收集。当回答改变范围或引入必须验证的内容时，重复调研。
4. 停止条件
仅在以下情况退出循环：结果、范围、约束、优先级与成功标准已充分定义；相关仓库事实、集成点、风险与验证路径已检查；重要未知项已解决、明确接受为假设或记录其规划影响；近期澄清未引入未调研的问题；仓库证据足以定义有意义、可审查的阶段，包含前置条件、输出、风险与验证。
若阻塞性决策无法解决，不要编造答案；清楚暴露它，或说明计划尚无法最终确定。
发现后的规划工作流
设计均衡阶段
每个阶段通常代表约 30–90 分钟的专注工作。让每个阶段自包含，具有清晰的前置条件、输出与验证。避免增加协调开销而无有意义检查点的微阶段。拆分混合无关结果或难以审查的过大阶段。标记可并行运行的阶段。最终阶段与依赖决策由主规划者保留。
先草拟与审阅，再写入
按所选细节程度草拟完整计划，但不写入文件。对于简洁计划，呈现完整草稿。对于较长计划，呈现完整草稿或忠实的逐节摘要。请用户批准、请求编辑或拒绝。修订并重新审阅，直到用户明确批准内容。
只写入一个计划文件
只将已批准的计划写入所选目标位置。保持结构化、具体，并可在执行期间更新。
总结
回顾整体方法、主要阶段、主要风险或未决问题，以及保存路径。
计划要求
推荐章节：
# Implementation Plan: <Task Name>
## Overview
## Global Context
## Architecture Decisions
## Assumptions
## Phase Strategy
## Phases
## Phase Dependencies
## Risks
## Questions for User
阶段模板，每个阶段应包含：
- Objective
- Status: Not Started
- Complexity
- Estimated Time
- Prerequisites
- Context for this Phase
- Files table
- Implementation Tasks as markdown checkboxes
- Execution Tracking Rules
- Verification
- Completion Gate
- Outputs
执行跟踪规则：
- 初始状态必须为 Not Started
- 执行开始时，阶段状态应在阶段特定工作流设置前变为 In Progress
- 已完成任务应勾选
- 跳过或取代的任务应划掉，而非虚假标记为完成
- 仅在用户审阅结果并明确确认完成后，阶段才变为 Complete
- 若项目使用检查点工作流，该阶段的清理或收尾应在用户确认完成后立即进行
版本控制指导：
若仓库使用版本控制且用户需要工作流指导，包含一个与其选择匹配的策略章节。保持术语通用，按意图描述工作流。可能的策略：
- 每个阶段使用独立工作目录
- 每个阶段使用独立功能分支
- 共享分支上的检查点标签
- 每个阶段开始时单独决定策略
对于所选策略，说明：阶段执行如何开始；依赖如何影响后续阶段；用户确认阶段完成后必须做什么；如何避免留下未完成的阶段状态。不要在技能文本中依赖特定运行环境的命令或工具名。
适用场景
- 复杂、多文件、多系统或高风险任务的实施规划
- 重构、迁移、架构更新
- 需要交接给其他代理或人类执行者的分阶段计划
- 用户要求路线图、任务拆解或实施策略
限制
- 规划模式下不实现代码
- 不编造未检查的仓库细节
- 在设计阶段前必须完成信息收集 → 调研 → 澄清循环
- 当能力可用时，循环中至少使用一个有边界的只读子代理
- 所有用户交互、规划决策、审批与文件写入由主规划者负责
- 用户审阅并明确批准前不写入计划文件
- 保持计划指令可在不同代理环境中执行
- 除非用户明确要求特定运行环境变体，否则不提及特定产品工具名
- 保存计划后，以简洁总结与保存路径回应
质量要求
该技能产出的好计划应：反映真实仓库发现；暴露重要假设与风险；为交接给另一执行者提供足够上下文；保持同级阶段合理均衡；尽可能给出客观验证标准；避免“按需更新代码”等模糊步骤；综合委派发现而非不加批判地复制。