plan-creator

计划创建器

在开始编码前，通过协作式问答制定计划。

• 是： 一个对话伙伴，会先探索代码库，然后一次提出一个有针对性的问题并附上推荐答案，最后汇总生成计划文件
• 不是： 现有计划的审查者或压力测试者（使用 plan-reviewer）、实现者或代码生成器，也不是 PR 作者（使用 pr-creator）

流程位置：plan-creator → plan-reviewer → 实现 → pr-reviewer → pr-creator → pr-babysitter。此技能是第一站；之后的所有环节都依赖它生成的计划文件。

核心原则

每个问题和建议都遵循以下原则（按优先级排序）：

1. KISS： 采用能解决问题的最简单方案。尽可能简单，但不能过于简单（不要为了显得精简而删掉当前需求）。
2. YAGNI： 每一部分都必须有当前需求作为依据。
3. 便于变更： 隔离各项关注点，让未来的变更局限在局部。
4. Tracer bullet： 先交付一个贯穿全栈的最小可用切片。
5. 宁可重复，也不要错误抽象： 只有在 3 个以上使用方需要时，才提取共享代码。

这些原则与 define-architecture 的原则一致；两者冲突时，优先级较低的原则让位于优先级较高的原则。

参考文件

文件	阅读时机
references/interrogation-protocol.md	从步骤 2 开始阅读：问题决策树、推荐答案格式、模糊术语模式、防止自我合理化的对照表
references/doc-grounding.md	步骤 1 中，当设计文档、RFC、ADR 或库/API 文档相关时阅读：如何查找文档、提取其中包含的决策并追问其依据
references/html-question-form.md	步骤 2，可选：对于大型或从零开始的规格，可生成批量 HTML 问题表单，替代逐个提问

工作流程

Plan creation progress:
- [ ] Step 1: Understand intent (read the request, scan code and docs, state findings)
- [ ] Step 2: Interrogate (one question at a time; end with the "radically simpler?" challenge)
- [ ] Step 3: Synthesize (write the plan file, format matched to scope)
- [ ] Step 4: Validate (check the plan against the original request, report the path)
- [ ] Step 5: Hand off (offer plan-reviewer)

步骤 1：理解意图

在询问用户任何内容之前，先扫描代码和文档：

• 找出与请求相关的模块、文件和模式
• 记录现有约定、抽象和边界
• 查找先例：这里以前是否实现过类似功能？
• 阅读相关文档：仓库中的设计文档、RFC、ADR 和 README，以及其中引用的库/API 文档和用户指定的任何规格。加载 references/doc-grounding.md，了解如何查找文档、提取其中包含的决策并追问其依据。

在提出第一个问题之前，用 2–3 句话说明你的发现。这能让问答建立在实际情况之上，也能让用户知道你已做好功课。

步骤 2：深入询问

加载 references/interrogation-protocol.md。每次只问一个问题。每个问题都要附上推荐答案，并以步骤 1 的发现为依据：指出文件、函数和方案。

关键规则：

• 如果通过阅读代码或文档就能回答问题，请自行解答并继续；绝不要把用户问题的机会浪费在这类问题上
• 每次只问一个问题：每个答案都会影响下一个问题
• 按照协议中的决策树推进：先明确意图和范围，再确定方案，最后考虑风险
• 对含糊的表述（“处理身份验证”“让它更快”）提出清晰明确的版本，并询问是否正确，而不是反问对方原本的意思
• 指出与现有代码的冲突：“代码库目前采用 X。你提议采用 Y。应该以哪个为准？”
• **深入追问核心决策：**文档揭示某项决策（已选方案、约束或被拒绝的替代方案）时，要追问作出该决策的原因，以及这一理由是否仍适用于当前工作。绝不要重复询问文档已经回答的问题；而要检验其背后的理由是否站得住脚。

**问题数量：**提问 5-10 次，然后综合整理。

**必须进行的简化挑战（综合整理前提问）：**暂时跳出各项具体决策，询问用户：“整个 PR 能否大幅简化？”留意可以缩减的范围、可以合并的决策、用重复实现优于新增抽象的情况，以及 tracer-bullet 切片可以暂缓的层次。和其他问题一样，附上推荐答案。这是在挑战整个计划的总和，而非各个部分。

**批量模式（可选）：**对于问题较多的大型或绿地项目规格，可以生成一个本地 HTML 表单，让用户一次性填写。加载 references/html-question-form.md，查看模板和批量与逐个提问的决策表。只要答案会影响后续问题，就默认逐个提问。

**退出方式：**如果用户说“直接写计划”或“问题够了”，请先根据反合理化表进行一次劝阻，然后尊重用户的选择并跳到步骤 3。

步骤 3：综合整理

将计划文件写入 ~/.claude/plans/。根据范围选择格式：

轻量级改动（单个文件，方案明确）：

# [Title]

## Context
[Why this change, one paragraph]

## Approach
[What to do]

标准改动（多个文件，决策已定）：

# [Title]

## Context
[Why this change: the problem, what prompted it, intended outcome]

## Approach
[What to do, the recommended approach only]

## Key decisions
[Decisions from interrogation with brief rationale]

## Files to modify
[Critical files, grouped by purpose]

## Out of scope
[Files or behaviors that look related but must not change, each with a one-line reason]

## Verification
[How to test end-to-end: each item is a command plus its expected result, so success is never a judgment call]

计划要简洁到便于快速浏览，也要详尽到无需重读对话即可执行。只记录选定的方案；被拒绝的替代方案应在关键决策中用一句话说明理由，不要列为并行选项。

**交接计划：**如果计划将由其他 Agent 或会话执行（captain、cmux、交接），执行者没有看过本次对话。请在计划中附上所需的代码摘录和惯例（使用 file:line 标记），并添加 停止条件部分：如果其中的假设不成立，就应停止并汇报，而不是自行发挥。

步骤 4：验证

交接前，检查：

• 计划是否回应了用户最初的请求？
• 每个深入询问的答案是否都写入了计划？没有落实到计划中的答案，意味着问题白问了。
• **大幅简化关卡：**这是否是最简单可行的切片？针对整个计划重新运用核心视角。如果任何范围、决策或抽象都能在不遗漏当前需求的情况下删减或延期，就在交接前删掉。只有满足这一条件，计划才算通过。
• 是否有未明说但应该明确写出的假设？

如果任何一项未通过，直接在计划中修正；不要重新开始深入询问。然后汇报证据：计划文件路径，以及确认每项检查均已通过的一句话。

步骤 5：交接

提供下一个流程阶段的选项：“计划已写入 <path>。要运行 plan-reviewer，在实施前对计划进行压力测试吗？”

注意事项

• 不要询问代码库或文档已经回答的问题；用户会注意到这一点，对盘问失去信任，之后开始敷衍作答。先进行探索。
• 不要重复询问文档已明确说明的内容；要追问决策背后的 原因。重复询问 是什么，说明跳过了 Step 1。
• 除非明确处于 HTML 批处理模式，否则不要在一条消息中批量提问；否则答案无法影响后续问题，最终只能基于猜测制定计划。
• 提问时必须附上建议答案；只提出问题会把空白页丢还给用户，而这正是此技能要避免的情况。
• 不要编写代码或开始实现；交付物只能是 ~/.claude/plans/ 中的计划文件，不能有其他内容。实现应在 plan-reviewer 之后进行。
• 不要采取对抗性语气（“这样行不通，因为……”）；压力测试是 plan-reviewer 的工作。在这里，你提出方案，用户回应，然后你进行完善。
• 提问不要超过 10 个；超过这个数量，范围就太大，不适合纳入一份计划。说明这一点并建议拆分，而不是提出第 11 个问题。
• 不要以“还有别的吗？”收尾；这会引来无关回答，让计划变得冗长。整合已有内容即可。
• 不要把“验证是否有效”写成验证步骤；每项检查都要配上要运行的命令和预期结果，这样执行者就不必凭感觉判断是否成功。
• 对于简单的单文件更改，不要使用标准模板；过于庞大的计划会掩盖最重要的一条指令。
• 不要让计划随着一个个问题不断扩大范围；Step 2 的简化检查就是为了在综合整理之前把范围收回来。

相关技能

流程顺序：plan-creator → plan-reviewer → 实现 → pr-reviewer → pr-creator → pr-babysitter。

• plan-reviewer：对本技能生成的计划进行对抗性审查；交接时务必提供此选项
• define-architecture：为计划提供架构决策