skill-make-plan

name: make-plan
description: 创建分阶段的详细实施计划，并包含文档调研。当需要为某个功能、任务或多步骤实现做规划时使用——尤其是在用 do 执行之前。

你是一名编排者（ORCHESTRATOR）。请制定一份对 LLM 友好的分阶段计划，使其能在全新的对话上下文中被连续执行。

委派模型

把事实收集与提取（文档、示例、函数签名、grep 结果）交给子代理（subagent）。把综合与计划撰写（阶段划分、任务定义、最终措辞）留给编排者本人。如果某个子代理的汇报不完整或缺乏证据，请在定稿前用有针对性的读取 / grep 重新核实。

子代理汇报约定（强制）

每个子代理的回复必须包含：
1. 查阅过的来源（文件 / URL）以及读了什么
2. 具体发现（确切的 API 名称 / 签名；确切的文件路径 / 位置）
3. 可直接复制的片段位置（要复制的示例文件 / 章节）
4. "置信度"说明 + 已知缺口（可能还遗漏了什么）

如果子代理给出结论却没有来源，请驳回并重新派遣它。

计划结构

阶段 0：文档调研（永远放在最前）

在规划具体实现之前，先派遣"文档调研"子代理去：
1. 搜索并阅读相关文档、示例和既有模式
2. 确认真实可用的 API、方法和签名（不靠臆测）
3. 整理一份"允许使用的 API"清单，并引用具体的文档来源
4. 标注需要避开的反模式（不存在的方法、已废弃的参数）

编排者把这些发现汇总成一份统一的阶段 0 产出。

每个实现阶段必须包含

1. 要实现什么 —— 把任务定义为从文档中复制，而不是改写既有代码
2. 好："从 docs/examples.ts:45-60 复制 V2 会话模式"
3. 差："把现有代码迁移到 V2"
4. 文档引用 —— 引用具体的文件 / 行号，指明要遵循的模式
5. 验证清单 —— 如何证明这一阶段成功（测试、grep 检查）
6. 反模式防护 —— 明确不该做什么（臆造 API、未文档化的参数）

最终阶段：验证

1. 核对所有实现是否与文档一致
2. 检查反模式（grep 查找已知的坏模式）
3. 运行测试以确认功能正常

核心原则

• 文档存在 ≠ 被使用：明确要求去阅读文档
• 任务的措辞很重要：把代理指向文档，而不仅仅指向结果
• 验证优先于臆测：要求证据，而非对 API 的假设
• 会话边界：每个阶段都应自成一体，带有自己的文档引用

要预防的反模式

• 臆造"本应存在"的 API 方法
• 添加文档中没有的参数
• 跳过验证步骤
• 不查看示例就假设结构

另见

• oh-my-issues —— 它是 issue 侧的姊妹工具。当你被要求制定的计划源于 bug 或功能待办池、而非全新想法时，先走 oh-my-issues：按根因把 issue 聚类成若干 plan master 和 plans/0X-*.md 设计文档。随后 make-plan 针对其中某一个计划切片的设计文档来运作。

作者：张少楠