用途
write-plan 是一个仅用于规划的技能，目标是为复杂或高风险的变更产出完整、自包含、可由 execute-plan 执行的实施方案，即使经过 /clear 或由另一个智能体接手，也能把歧义降到最低。它明确不做代码实现，也不修改生产文件（计划产物除外）。
主要能力与工作流程
- 上下文加载（Contextualize）：如果存在 docs/SUMMARY.md 会优先阅读；只加载与任务相关的细节文档；优先参考 Code Standard 文档中的实现约定。如果文档与代码或用户意图冲突，在广泛变更前使用可用的输入/提问工具确认。随后只检查与请求变更相关的代码区域，并记录用户可见目的与预期结果、可沿用的既有模式、约束与依赖、帮助执行者定位的文件与命令、以及风险、假设与未知项。
- 初始化计划产物：创建 docs/.plans/YYMMDD-HHmm-<plan-slug>/ 目录，内含 SUMMARY.md，以及每个实施阶段一个阶段文件（命名约定 phase-XX-<name>.md）；仅在需要时添加 research/ 目录。文件夹与文档时间戳使用共享 General Principles 中的时间戳命令。
- 澄清需求：通过提问解决请求中的歧义，聚焦范围与边界、成功标准、约束与非目标、优先级与权衡。若需求已明确或来自 brainstorm 上下文，可跳过确认步骤。假设需在 SUMMARY.md 中显式说明；若请求存在多种解读，应列出并询问，不得静默选择。
- 定义策略与阶段：设计安全且可验证的分阶段策略。每个阶段需包含清晰目标、适合该阶段的复杂度与风险等级（S、M、L、XL）、有序任务、验证命令、可观察的验收标准与退出条件。任务应小而具体；优先设计可安全恢复的阶段，对高风险工作记录幂等性、恢复说明或回滚约束。
- 研究（仅在需要时）：研究为可选，且与不确定性成正比。优先顺序为：现有项目文档与代码、现有技能与本地参考、外部参考（仅当当前环境可用）。若无法进行外部研究，则基于本地证据推进，并明确列出假设与开放问题。研究发现记录在 docs/.plans/YYMMDD-HHmm-<plan-slug>/research/<topic>.md。
- 撰写计划产物：SUMMARY.md 与 phase-XX-<name>.md 分别遵循 references/summary-template.md 与 references/phase-template.md 中的模板。使用 visualize 技能可视化计划；若存在 --non-visualize，则跳过可视化。
- 评审与细化：呈现计划前核查路径是否精确一致、阶段顺序是否合理、任务是否可操作（无模糊步骤）、每个阶段是否定义验证、验收标准是否可观察、风险与假设是否显式、计划是否无需当前对话的隐藏上下文即可执行。若存在多种可行方案，使用输入/提问工具让用户选择：确认当前计划执行、或通过补充澄清问题进一步细化。
- 交接：以“Plan
<relative_path_to_plan>/SUMMARY.mdis ready.”结束；若已生成可视化，同时给出“Visualization<relative_path_to_plan>/visualize.htmlis ready.”。
规则与限制
- 不在同一会话中自动实现或执行代码变更；仅在用户选择后允许生成可选的计划可视化，且仅针对计划产物。
- 优先使用显式文件路径与具体命令，与项目标准及既有架构保持一致。
- 计划需自包含、确定性强、可恢复，仅凭计划文件夹即可让新的智能体继续工作。
- 规划最小可行变更：不设推测性阶段，不做“以防万一”的抽象，不引入未被要求的灵活性；若 3 个阶段可完成就不要写 6 个，每个任务都应直接对应已声明需求。
- 计划产物使用与当前会话相同的语言撰写。
适用场景
适用于 ExecPlan 风格的工作、需要数小时的变更，以及复杂或高风险、需要明确分阶段与验证的实施任务。
暂未提供的信息
关于收费、价格、平台支持范围、具体效果指标等细节，资料中暂未提供。