philip-cao-9527/code-note-helper/plan-mode-planner

plan-mode-planner

技能定位

生成一份“要求 Codex 使用 Plan mode 的 prompt”。这个 skill 不直接执行实现，不直接替用户选择技术路线，也不把计划写成已经确定的实现方案。

它适合高风险、多阶段、架构取向未定、用户明确要求“先计划”“先给选择空间”“先不要改代码”的任务。最终产物是一段可复制给 Codex/Agent 的 prompt，要求执行者先进入 Plan mode，读真实仓库后再提炼少数关键决策点。

使用流程

1. 先确认用户需要的是 Plan mode prompt，而不是直接实现或普通执行 prompt。
2. 读取项目规则、README、开发日志、相关模板或用户给出的背景材料。
3. 读取 references/plan-template.md，按本轮任务填充：

• 仓库路径、任务主题、项目背景。
• 必读文件、参考材料、硬性边界。
• 需要在 Plan mode 提炼的关键决策类型。
• 禁止一开始写死的技术细节。
• 用户选择后的实现验证要求和交付物顺序。

1. 输出一个完整、连续、可复制的 Plan mode prompt。

Skill 交叉引用规则

如果生成的 Plan mode prompt 需要指向其他 skill，必须使用 $skill-name 形式引用，例如 $project-prompt-creator 或 $code-reviewer。不要只写反引号包裹的 skill 名称，也不要把 skill 名称写成普通说明。

Plan mode prompt 核心规则

最终 prompt 必须要求执行者：

• 先使用 Plan mode。
• 不允许跳过计划阶段直接实现。
• 不允许一开始就写死详细技术方案。
• 不允许直接给用户几个已经具体到实现细节的方案让用户盲选。
• 先阅读真实仓库、参考材料和约束。
• 再提炼少数真正需要用户拍板的关键决策点，优先控制在 2 到 4 个。
• 决策点必须是大方向、结构取向、长期偏好或风险承受边界，不是琐碎实现细节。
• 每个决策点要说明为什么必须决策、不同取向影响什么、当前倾向是什么，但不能替用户拍板。
• 用户选择后再收敛具体方案，然后才进入实现。

质量要求

• 最终 prompt 要像执行指令，不像解释 Plan mode 的教程。
• 不要把计划 prompt 写成已经定稿的技术方案。
• 不要把能通过读取仓库解决的问题丢给用户。
• 决策点要少而关键；超过 4 个通常说明还没有完成归纳。
• 禁止保留空标题、空占位符或“视情况处理”这类不可检查表达。

输出包裹规则

• 最终 Plan mode prompt 必须整体放入一个 Markdown 文本块。
• 如果 prompt 内部包含三反引号，外层使用四反引号或更长围栏。
• 输出代码块前最多写一句中文引导；输出代码块后不要追加额外正文。

自检

输出前逐条检查：

1. 是否明确这是生成 Plan mode prompt，不是直接执行计划。
2. 是否要求执行者先只读探索，再提炼关键决策。
3. 是否禁止跳过计划阶段直接实现。
4. 是否把用户决策控制在 2 到 4 个关键点。
5. 是否没有替用户拍板，也没有把琐碎实现细节包装成决策点。
6. 如果 prompt 中交叉引用其他 skill，是否统一使用 $skill-name 形式。
7. 是否包含实现后验证要求和交付物顺序。