planning

规划

通过交互式、迭代式流程制定详细的实施计划。保持审慎、全面，并积极协作。

设置（开始前）

1. 自主模式 — 由调用命令传入；如果未指定，默认为 Critical。

   模式	行为
   Autopilot	独立开展研究、编写完整计划，仅提交最终版本供审核
   Critical（默认）	每完成一个研究步骤后，先提出澄清问题再起草；在决策点展示设计选项
   Verbose	每个子步骤都进行确认：验证理解、确认范围、指出未知事项，并在每个阶段开始前征求确认

2. 提交偏好与编排 — 除非处于 Autopilot 模式，否则通过 AskUserQuestion 询问一次（在一次调用中合并两个问题；如果当前会话中没有 Workflow 工具，则省略第二个问题）：

   问题	选项
   “手动验证通过后，是否在每个阶段完成后创建一次提交？”	1. 是（推荐），2. 否，由我处理提交
   “是否将研究探索作为 Workflow 脚本运行？（可使用更多并行 Agent，但会消耗更多令牌）”	1. 是 — Workflow 分发，2. 否 — 普通子 Agent（默认）

   对第二个问题回答“是”，即明确同意使用 Workflow 工具。在 Autopilot 模式下（不提问），默认使用普通子 Agent。

3. 过往经验 — **可选子技能：**如果 ~/.agentic-learnings.json 存在，先运行 /learning recall <topic>。

4. 设计文档（阅读并遵循） — 如果有适用于所涉系统的设计文档（thoughts/*/design-docs/<system-slug>.md），研究前先阅读：在计划中使用其中的术语表，不要违反其中的不变量或边界，并将冲突作为明确事项提交用户决策，不要默默绕开。如果计划有意变更设计，应将更新文档（决策日志 + 修订日志）列为计划步骤。参见 desplega:design-docs。

10 条规则

1. 先搭建框架 — 开始任何研究前，先退出计划模式，并根据 cc-plugin/base/skills/planning/template.md 创建 thoughts/<username|shared>/plans/YYYY-MM-DD-description.md。（已知用户姓名时使用其姓名，例如 taras；否则使用 thoughts/shared/。）文件应逐步完善，让用户能尽早纠正方向。

2. 繁重工作交给子 Agent — 文件读取、研究和验证都交给子 Agent。默认使用 run_in_background: true。不要将原始工具输出放入主会话。 子 Agent 选项： codebase-locator（查找文件）、codebase-analyzer（理解当前实现）、codebase-pattern-finder（查找类似功能）、context7 MCP（库／框架的具体信息）、Explore 或 general-purpose（读取提及的文件）。 执行器分配： 如果有 desplega:delegate-work，根据其矩阵为每个子 Agent 选择模型（查找 → Haiku，分析 → Sonnet），不要使用默认模型启动。如果在设置阶段选择了 Workflow 分发，则将每个章节的研究探索作为 Workflow 脚本运行（model／effort／agentType 选项遵循同一矩阵）——计划起草始终由主会话负责。

3. 通过 AskUserQuestion 提问 — 参见 desplega:ask-user 中的约定。绝不要在聊天中以普通项目符号提问。

4. 每步后提问（Critical／Verbose），再继续迭代 — 按章节逐步完善计划：当前状态分析 → 实施方案 → 阶段概要 → 阶段详情。每个章节都按以下流程处理：启动子 Agent → 综合研究结果（附 file:line 引用）→ 通过 AskUserQuestion 询问缺失信息 → 起草 → 进入下一章节。假设的输入是计划不佳的首要原因。

5. 每个阶段都要有具体交付成果 — 每个阶段的概述都要说明完成后会产出哪些文件、功能或其他成果。“改进 X”“重构 Y”都应视为警示信号。

6. 工作成果：最大限度地采用自动化验证 + 自动化 QA — 尽可能将所有内容转化为可运行的命令（低层级），并采用 Agent 驱动的 QA（浏览器操作、截图差异比对、CLI 演练）。手动验证是例外。只有在涉及跨领域或需要大量证据的 QA 时，才使用单独的 ### QA Spec (optional): 链接到 desplega:qa 文档——不要用于常规的分阶段检查。

7. 建议拆分 — 当某个阶段包含超过 4 个子步骤或超过 2 个不同关注点时，将其拆分。如果计划无法在一次实现会话中完成，就拆成多个更小的计划（例如：契约 → 存储 → UI）。反过来也成立：如果整个任务在一个子系统内只需约 1–3 个阶段即可完成，建议使用 /one-shot（desplega:one-shot），而不是完整计划。

8. 直言不讳地提出异议 — 如果计划过于庞大、含糊、混杂多个关注点或存在明显风险，请使用 desplega:feedback。过度设计也要纳入考量：依据 desplega:engineering-standards（删除测试、双适配器规则、新依赖测试）评估提出的抽象、分层和新依赖，并按照其中的 Pushback 协议具体指出问题，同时概述更简单的替代方案。沉默是毁灭性的同理心。

9. 展示计划前，使用 Haiku 子 Agent 验证结构（general-purpose，model: haiku）。验证：每个阶段都包含全部三个 Success Criteria 子章节；所有条目都使用 - [ ]；自动化检查都是可运行的命令；引用的路径均存在。展示前先应用修正。

10. 交接给全新会话——切勿在此处实现。 收尾步骤：

    1. 打开 /file-review:file-review <plan-path>（Autopilot 除外）；根据评论反复修改。

    2. 可选：调用 desplega:reviewing 进行差距分析（通过 AskUserQuestion 提供此选项）。

    3. 可选子技能： 如果产生了重要见解，通过 /learning capture 记录。

    4. 如果任一阶段包含 ### QA Spec (optional): 块， 则在交接前通过 desplega:qa 生成 QA 文档（thoughts/<username|shared>/qa/YYYY-MM-DD-[feature].md）。场景应写在文档中，而不是计划里。

    5. 通过 AskUserQuestion 询问用户：

       问题	选项
       "计划已就绪。接下来要做什么？"	1. 在全新会话中实现，2. 先运行 /review，3. 暂时完成（搁置计划）

    6. 明确告知用户："打开一个新的 Claude Code 会话并运行 /desplega:implement-plan <path>。从全新会话开始可以保持干净的实现上下文。"

提交集成

如果在 Setup 中启用了每阶段提交：

• 每个阶段的手动验证通过后，按 [phase N] <brief description> 格式提交。
• 仅在明确确认手动验证已通过后提交。
• 否则跳过提交——由用户自行处理。

Success Criteria 格式（必需）

规范格式和标题层级见 cc-plugin/base/skills/planning/template.md。结构验证会自动运行（规则 9，Haiku 子 Agent）。