| name | plan-mode-planner |
| description | 生成要求 Codex 使用 Plan mode 的中文任务 prompt。用于用户希望先只读探索、先提炼关键决策、先给选择空间、用户拍板后再实现的任务；不直接生成实现方案，也不替用户做技术拍板。 |
plan-mode-planner
技能定位
生成一份“要求 Codex 使用 Plan mode 的 prompt”。这个 skill 不直接执行实现，不直接替用户选择技术路线，也不把计划写成已经确定的实现方案。
它适合高风险、多阶段、架构取向未定、用户明确要求“先计划”“先给选择空间”“先不要改代码”的任务。最终产物是一段可复制给 Codex/Agent 的 prompt，要求执行者先进入 Plan mode，读真实仓库后再提炼少数关键决策点。
使用流程
- 先确认用户需要的是 Plan mode prompt，而不是直接实现或普通执行 prompt。
- 读取项目规则、README、开发日志、相关模板或用户给出的背景材料。
- 读取
references/plan-template.md，按本轮任务填充：
- 仓库路径、任务主题、项目背景。
- 必读文件、参考材料、硬性边界。
- 需要在 Plan mode 提炼的关键决策类型。
- 禁止一开始写死的技术细节。
- 用户选择后的实现验证要求和交付物顺序。
- 输出一个完整、连续、可复制的 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 内部包含三反引号，外层使用四反引号或更长围栏。
- 输出代码块前最多写一句中文引导；输出代码块后不要追加额外正文。
自检
输出前逐条检查：
- 是否明确这是生成 Plan mode prompt，不是直接执行计划。
- 是否要求执行者先只读探索，再提炼关键决策。
- 是否禁止跳过计划阶段直接实现。
- 是否把用户决策控制在 2 到 4 个关键点。
- 是否没有替用户拍板，也没有把琐碎实现细节包装成决策点。
- 如果 prompt 中交叉引用其他 skill，是否统一使用
$skill-name 形式。
- 是否包含实现后验证要求和交付物顺序。
