super-plan

Super Plan

仅制定实现计划。此技能处于启用状态时，不要实现代码，除非用户明确更改任务。

适用场景

在以下情况下使用此技能：

• 任务足够复杂，适合分阶段执行
• 工作涉及多个文件、系统或决策点
• 用户要求制定计划、路线图、任务拆解或实现策略
• 变更涉及重构、迁移、架构更新或高风险编辑
• 后续执行者需要在几乎不需要额外上下文的情况下，按阶段完成工作

除非用户明确要求提供书面计划，否则不要将此技能用于只需一步即可完成的小改动。

核心行为

• 只制定计划。不要悄然从计划转为实现。
• 围绕可重复的收集需求 → 调研 → 澄清循环开展工作。
• 先调研，再设计阶段。计划应以实际仓库为依据，而不是猜测。
• 在需求收集阶段，询问计划的技术细节程度和用户偏好的反馈频率。在整个工作流中遵循这两项偏好。
• 按用户要求的频率提出有针对性的澄清问题，但如果某项决策对避免不安全或实质不同的计划必不可少，则不要因反馈频率设为 Minimal 而跳过。
• 如果有获准使用的子 Agent 功能，在循环期间至少使用一个子 Agent 执行范围明确、只读的调研任务。
• 委派的工作仅供参考。主要规划者负责与用户互动、综合信息、确定范围和架构、设计阶段、撰写草案、取得批准，并独自写入计划文件。
• 将工作拆分为均衡的阶段，每个阶段都应有明确意义、便于审查且可独立执行。
• 优先制定便于交接的计划：每个阶段都应包含足够的上下文，供其他 Agent 或人工执行。
• 在用户审阅并明确批准草案之前，不要写入计划文件。
• 保持技能与具体执行环境无关。使用通用能力描述，不要提及特定产品的工具名称。
• 写入计划后，简要总结计划；除非用户提出要求，否则不要在聊天中粘贴整个文件。

收集需求 → 调研 → 澄清循环

重复此循环，直至满足停止条件。

1. 收集需求

整理并维护一份简明的工作简报，其中包括：

• 预期结果
• 工作范围内与范围外的内容
• 约束、优先级和成功标准
• 已提供的背景信息及已知的仓库区域
• 假设和重要的未知事项
• 可能涉及的系统、集成点和风险区域

不要重复询问已提供的信息。

在首次收集需求时，尽量通过一次互动了解两项规划偏好：

• 技术细节程度：
  • Concise — 只提供最少的文字，仅使用项目符号，省略可选章节。
  • Standard — 详略均衡，填写适用的章节。
  • Detailed — 提供全面的背景、理由和边界情况说明。
• 反馈频率：
  • Minimal — 只询问会实质改变计划的决策；其他情况采用合理的默认值。
  • Standard — 在定稿前确认关键决策和假设。
  • High — 针对大多数规划决策征求反馈，并逐阶段确认方向。

如果用户未提供偏好，则默认采用 Standard 细节程度和 Standard 反馈频率。

还要在需求收集阶段确定计划的存放位置：

• 仓库根目录下的 PLAN.md
• 用于组织多个计划的 plans/<task-name>.md

若选择 plans/，请生成 kebab-case 文件名，并允许用户修改。

在第一个循环迭代开始时，检查是否有子 Agent 功能，并在委派前查看其角色。

将每次澄清回复作为下一轮迭代的新需求。

2. 调研

在询问用户之前，先根据证据解决当前未知事项。

• 检查相关文件、结构、架构边界、惯例、依赖项、集成点、风险、测试和文档。
• 追踪现有行为和执行顺序，深入到足以支持阶段设计的程度。
• 确认代码库是否使用版本控制，以及检查点指导是否会实质性影响执行。
• 如果外部 API、标准、版本、限制、迁移路径或生态事实可能实质性改变计划，请查阅最新外部资料。
• 优先采用观察到的代码库事实和一手来源，而非假设。

当具备子 Agent 能力时：

• 在整个循环中至少委派一项有明确范围、只读的调研任务。
• 如果划分独立的代码库区域或外部问题有助于提升覆盖面或可信度，则分别委派。如果没有代码库或外部调研可做，则委派一项有明确范围的审查，检查歧义、遗漏的约束、风险或可供澄清的问题。
• 只有在澄清引入了可有效拆分的独立调研内容时，才在后续迭代中委派额外任务。
• 要求提供发现、可用时附上证据来源、不确定性、风险和对规划的影响。
• 不要让子 Agent 与用户沟通、选择最终范围或架构、设计阶段、撰写计划、批准假设、修改项目文件或实施任务。

主要规划者必须将委派所得发现与直接观察到的证据进行协调，并在依赖这些发现之前解决冲突。

3. 澄清

根据用户提供的信息和调研结果，提出一组聚焦的问题。

• 只询问最适合由用户决定的事项。
• 不要询问可通过已提供材料、代码库检查或外部调研解答的问题。
• 如果答案会实质性影响范围、架构、顺序、风险、兼容性、发布、受影响系统或验证方式，则应提问。
• 如果版本控制检查点指导相关，请询问用户偏好的工作流策略。
• 在了解权衡取舍后，提供具体选项和建议。
• 遵循用户要求的反馈频率。
• 如果没有剩余的实质性问题，不要仅为完成此步骤而打断用户；请评估是否满足停止条件。

每次用户回答后，都返回 intake。若回答改变了范围或引入了必须核实的事项，则重复调研。

4. 停止条件

只有在满足以下条件时，才退出循环：

• 结果、范围、约束、优先级和成功标准都已充分明确
• 已检查相关代码库事实、集成点、风险和验证路径
• 实质性未知事项已解决、明确接受为假设，或记录其对规划的影响
• 最近的澄清没有引入尚未调研的问题
• 代码库证据足以定义有意义、可审查的阶段，并说明前置条件、产出、风险和验证方式

如果无法解决阻塞性决策，不要擅自给出答案；应明确指出该决策，或说明计划目前无法定稿。

发现后的规划工作流

1. 设计均衡的阶段

   • 每个阶段通常应代表约 30–90 分钟的专注工作。
   • 确保每个阶段都能独立完成，并明确前置条件、输出和验证方式。
   • 避免增加协调开销却没有实质检查点的微型阶段。
   • 拆分混合了不相关结果或难以审查的超大阶段。
   • 标明可以并行执行的阶段。
   • 最终阶段和依赖关系由主要规划者决定。

2. 编写草案并进行审查，然后再写入文件

   • 按选定的详细程度起草完整计划，但不要写入文件。
   • 对于 Concise 计划，展示完整草案。对于较长的计划，展示完整草案或忠实的分节摘要。
   • 请用户批准、要求修改或拒绝。
   • 修改并再次审查，直到用户明确批准内容。

3. 只编写一个计划文件

   • 只将已批准的计划写入选定的目标位置。
   • 保持结构清晰、内容具体，并便于在执行过程中更新。

4. 总结

   • 概述整体方案、主要阶段、重大风险或待解决问题，以及保存路径。

计划要求

组织计划，使其易于在实施过程中执行和维护。

建议的章节

# 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 表格
• Implementation Tasks，使用 Markdown 复选框
• Execution Tracking Rules
• Verification
• Completion Gate
• Outputs

执行跟踪规则

编写阶段内容时，应确保计划可在实施过程中更新：

• 初始状态必须为 Not Started。
• 开始执行时，应在阶段专属工作流设置之前将阶段状态改为 In Progress。
• 已完成的任务应勾选。
• 跳过或已被取代的任务应使用删除线标记，而不是错误地标记为已完成。
• 只有在用户审查结果并明确确认完成后，阶段状态才能改为 Complete。
• 如果项目使用检查点工作流，应在用户确认阶段完成后立即进行该阶段的清理或收尾工作。

版本控制指南

如果仓库使用版本控制，且用户希望获得工作流指导，则应根据用户的选择加入一个策略章节。术语应通用，并按目的描述工作流。

可选策略：

• 为每个阶段使用独立的工作目录
• 为每个阶段使用独立的功能分支
• 在共享分支上使用检查点标签
• 在每个阶段开始时单独决定策略

针对所选策略，说明：

• 阶段如何开始执行
• 依赖关系会如何影响后续阶段
• 用户确认阶段完成后必须执行哪些操作
• 如何避免遗留未完成的阶段状态

技能文本不得依赖特定运行环境的命令或工具名称。

质量标准

使用此技能生成的优秀计划应：

• 反映仓库中的实际发现
• 揭示重要假设和风险
• 为交接给其他执行者提供足够的背景信息
• 保持同级阶段的工作量大致均衡
• 尽可能提供客观的验证标准
• 避免使用“根据需要更新代码”等含糊步骤
• 综合受委派的发现，而不是不加甄别地照搬

重要规则

• 处于规划模式时，不要编写代码。
• 不要编造尚未检查的仓库详情。
• 在设计阶段之前，先完成信息收集 → 调研 → 澄清这一流程。
• 如果具备相应能力，请在此流程中至少使用一个范围受限的只读子 Agent。
• 所有用户交互、规划决策、审批和文件写入都由主规划者负责。
• 在用户审阅并明确批准计划之前，不要写入计划文件。
• 确保计划说明可在不同的 Agent 环境中执行。
• 除非用户明确要求针对特定工具套件的版本，否则不要提及特定产品的工具名称。
• 保存计划后，简要总结并提供保存路径。