⚡

智能计划器Skill plan

智能计划器是一个用于创建全面、可操作工作计划的技能。它通过智能交互自动检测是否需要用户访谈（对于宽泛请求）或直接生成计划（对于详细请求），并支持共识模式（多视角验证）和审查模式（计划评估）。适用于软件开发等项目的前期规划，确保需求清晰、风险可控。关键词：计划、战略规划、工作流程、智能交互、需求分析、项目管理、SEO优化。

项目管理 0 次安装 0 次浏览 更新于 3/11/2026

name: 计划 description: 带有可选访谈工作流的战略规划

<目的> 计划技能通过智能交互创建全面、可操作的工作计划。它自动检测是否进行用户访谈（宽泛请求）或直接计划（详细请求），并支持共识模式（迭代的规划师/架构师/批评家循环）和审查模式（对现有计划的批评家评估）。 </目的>

<使用场景>

  • 用户希望在实施前进行规划 —— “计划这个”、“计划该”、“让我们计划”
  • 用户希望对模糊想法进行结构化需求收集
  • 用户希望审查现有计划 —— “审查这个计划”、--review
  • 用户希望就计划达成多视角共识 —— --consensus、“ralplan”
  • 任务宽泛或模糊，需要在编写代码前进行范围界定 </使用场景>

<不适用场景>

  • 用户希望自主端到端执行 —— 使用 autopilot 代替
  • 用户希望立即开始编码，任务明确 —— 使用 ralph 或委托给执行器
  • 用户提出可直接回答的简单问题 —— 直接回答
  • 任务是具有明显范围的单一专注修复 —— 跳过规划，直接执行 </不适用场景>

<存在理由> 不先理解需求就跳入编码会导致返工、范围蔓延和遗漏边缘情况。计划技能提供结构化需求收集、专家分析和质量把关的计划，使执行从坚实基础开始。共识模式为高风险项目增加多视角验证。 </存在理由>

<执行策略>

  • 基于请求具体性自动检测访谈模式与直接模式
  • 在访谈期间一次问一个问题 —— 从不批量提问
  • 在询问用户之前，通过 explore 代理收集代码库事实
  • 计划必须满足质量标准：80%+ 的声明引用文件/行，90%+ 的标准可测试
  • 共识模式在进入实施前需要明确用户批准 </执行策略>

<步骤>

模式选择

模式 触发条件 行为
访谈 宽泛请求的默认模式 交互式需求收集
直接 --direct，或详细请求 跳过访谈，直接生成计划
共识 --consensus、“ralplan” 规划师 -> 架构师 -> 批评家循环直到达成一致
审查 --review、“审查这个计划” 对现有计划的批评家评估

访谈模式（宽泛/模糊请求）

  1. 分类请求：宽泛（模糊动词、无特定文件、涉及3+个领域）触发访谈模式
  2. 问一个聚焦问题：使用 AskUserQuestion 获取偏好、范围和约束
  3. 先收集代码库事实：在问"你的代码使用什么模式？"之前，生成 explore 代理来查找，然后问有根据的后续问题
  4. 基于答案构建：每个问题都基于前一个答案
  5. 咨询分析师（Opus）获取隐藏需求、边缘情况和风险
  6. 创建计划：当用户表示就绪时：“创建计划”、“我准备好了”、“把它做成工作计划”

直接模式（详细请求）

  1. 快速分析：可选的简短分析师咨询
  2. 创建计划：立即生成全面工作计划
  3. 审查（可选）：如果请求，进行批评家审查

共识模式（--consensus / “ralplan”）

  1. 规划师创建初始计划
  2. 用户反馈：必须使用 AskUserQuestion 呈现草案计划，选项包括：
    • 继续审查 —— 发送给架构师和批评家评估
    • 请求更改 —— 返回步骤1，融入用户反馈
    • 跳过审查 —— 直接进入最终批准（步骤7）
  3. 架构师审查架构合理性（首选 ask_codex 带 architect 角色）。等待此步骤完成再继续步骤4。 不要并行运行步骤3和4 —— 并行 ask_codex 调用如果一个收到429速率限制错误可能触发级联失败。如果 ask_codex 因速率限制或429错误失败，等待5–10秒重试一次；如果再次失败，回退到生成 Task 带 subagent_type="oh-my-claudecode:architect"。
  4. 批评家根据质量标准评估（首选 ask_codex 带 critic 角色）。仅在步骤3完成后运行。应用相同重试/回退规则：速率限制错误时，短延迟后重试一次；第二次失败时，回退到 Task 带 subagent_type="oh-my-claudecode:critic"。
  5. 重新审查循环（最多5次迭代）：如果批评家拒绝，执行此闭环： a. 收集架构师和批评家的所有拒绝反馈 b. 将反馈传递给规划师生成修订计划 c. 返回步骤3 —— 架构师审查修订计划 d. 返回步骤4 —— 批评家评估修订计划 e. 重复直到批评家批准或达到最多5次迭代 f. 如果未达批准即达最大迭代次数，通过 AskUserQuestion 向用户呈现最佳版本，并注明未达专家共识
  6. 应用改进：当审查者批准并提出改进建议时，在继续前将所有接受的改进合并到计划文件中。具体来说： a. 从架构师和批评家响应中收集所有改进建议 b. 去重和分类建议 c. 用接受的改进更新 .omc/plans/ 中的计划文件（添加缺失细节、优化步骤、强化接受标准等） d. 在计划末尾的简短变更日志部分注明应用了哪些改进
  7. 批评家批准时（应用改进后）：必须使用 AskUserQuestion 呈现计划，选项包括：
    • 批准并执行 —— 通过 ralph+ultrawork 进入实施
    • 清空上下文并实施 —— 先压缩上下文窗口（规划后上下文大时推荐），然后通过 ralph 以保存的计划文件重新开始实施
    • 请求更改 —— 返回步骤1，融入用户反馈
    • 拒绝 —— 完全丢弃计划
  8. 用户通过结构化 AskUserQuestion UI 选择（从不以纯文本请求批准）
  9. 用户批准时：
    • 批准并执行：必须调用 Skill("oh-my-claudecode:ralph")，以 .omc/plans/ 中的批准计划路径作为上下文。不要直接实施。不要在规划代理中编辑源代码文件。ralph 技能通过 ultrawork 并行代理处理执行。
    • 清空上下文并实施：先调用 Skill("compact") 压缩上下文窗口（减少规划期间积累的令牌使用），然后调用 Skill("oh-my-claudecode:ralph")，以 .omc/plans/ 中的批准计划路径。当上下文窗口在规划会话后填充50%+时推荐此路径。

审查模式（--review）

  1. 从 .omc/plans/ 读取计划文件
  2. 通过批评家评估（首选 ask_codex 带 critic 角色）
  3. 返回裁决：批准、修订（带具体反馈）或拒绝（需要重新计划）

计划输出格式

每个计划包括：

  • 需求摘要
  • 接受标准（可测试）
  • 实施步骤（带文件引用）
  • 风险和缓解措施
  • 验证步骤

计划保存到 .omc/plans/。草案保存到 .omc/drafts/。 </步骤>

<工具使用>

  • 首次使用 MCP 工具前，调用 ToolSearch("mcp") 发现延迟的 MCP 工具
  • 使用 AskUserQuestion 用于偏好问题（范围、优先级、时间线、风险容忍度）—— 提供可点击 UI
  • 使用纯文本用于需要特定值的问题（端口号、名称、后续澄清）
  • 使用 explore 代理（Haiku，30秒超时）在询问用户前收集代码库事实
  • 使用 ask_codex 带 agent_role: "planner" 用于大范围计划的规划验证
  • 使用 ask_codex 带 agent_role: "analyst" 用于需求分析
  • 使用 ask_codex 带 agent_role: "critic" 用于共识和审查模式中的计划审查
  • 如果 ToolSearch 未找到 MCP 工具或 Codex 不可用，回退到等效的 Claude 代理 —— 从不因外部工具阻塞
  • 关键 —— 共识模式 ask_codex 调用必须顺序进行，从不并行。 Claude Code 当一个失败时取消同级工具调用（“同级工具调用错误”），所以如果在同一工具调用批次中运行架构师和批评家 ask_codex 调用，任一个碰到429速率限制将导致级联失败。总是等待架构师调用结果再发出批评家调用。
  • 在 ask_codex 速率限制（429）错误时：等待5–10秒重试一次。如果第二次尝试也失败，回退到等效的 Claude 代理（Task 带 subagent_type="oh-my-claudecode:architect" 或 "oh-my-claudecode:critic"）。
  • 在共识模式中，必须使用 AskUserQuestion 用于用户反馈步骤（步骤2）和最终批准步骤（步骤7）—— 从不以纯文本请求批准
  • 在共识模式中，用户批准时必须调用 Skill("oh-my-claudecode:ralph") 用于执行（步骤9）—— 不在规划代理中直接实施
  • 当用户在步骤7选择"清空上下文并实施"时：先调用 Skill("compact") 压缩积累的规划上下文，然后立即调用 Skill("oh-my-claudecode:ralph") 带计划路径 —— 压缩步骤在实施循环开始前释放上下文至关重要 </工具使用>

<示例> <好> 自适应访谈（问前收集事实）：

规划师：[生成 explore 代理："查找身份验证实现"]
规划师：[收到："身份验证在 src/auth/ 使用 JWT 和 passport.js"]
规划师："我看到你在 src/auth/ 使用 JWT 身份验证和 passport.js。
         对于这个新功能，我们应该扩展现有身份验证还是添加单独的身份验证流程？"

为什么好：先回答自己的代码库问题，然后问有根据的偏好问题。 </好>

<好> 一次一个问题：

问题1："主要目标是什么？"
答案1："提高性能"
问题2："对于性能，延迟还是吞吐量更重要？"
答案2："延迟"
问题3："对于延迟，我们优化 p50 还是 p99？"

为什么好：每个问题都基于前一个答案。聚焦且递进。 </好>

<差> 询问可查找的内容：

规划师："你的代码库中身份验证在哪里实现？"
用户："呃，我想在 src/auth 某处？"

为什么差：规划师应该生成 explore 代理来查找，而不是问用户。 </差>

<差> 批量提问多个问题：

"范围是什么？时间线呢？受众是谁？"

为什么差：一次三个问题导致浅薄答案。一次问一个。 </差>

<差> 一次呈现所有设计选项：

"这里有4种方法：选项A... 选项B... 选项C... 选项D... 你偏好哪个？"

为什么差：决策疲劳。先呈现一个选项带权衡，获取反应，然后呈现下一个。 </差> </示例>

<升级和停止条件>

  • 当需求足够清晰可以计划时停止访谈 —— 不要过度访谈
  • 在共识模式中，5次规划师/架构师/批评家迭代后停止并呈现最佳版本
  • 共识模式在开始任何实施前需要明确用户批准
  • 如果用户说"直接做"或"跳过规划"，必须调用 Skill("oh-my-claudecode:ralph") 过渡到执行模式。不要在规划代理中直接实施。
  • 当有不兼容的权衡需要业务决策时，升级给用户 </升级和停止条件>

<最终检查清单>

  • [ ] 计划有可测试的接受标准（90%+ 具体）
  • [ ] 计划在适用时引用特定文件/行（80%+ 声明）
  • [ ] 所有风险都有已识别的缓解措施
  • [ ] 没有无指标的模糊术语（“快” -> “p99 < 200ms”）
  • [ ] 计划保存到 .omc/plans/
  • [ ] 在共识模式中：用户在实施前明确批准 </最终检查清单>

<高级>

设计选项呈现

在访谈期间呈现设计选择时，分块进行：

  1. 概述（2-3句）
  2. 选项A 带权衡
  3. [等待用户反应]
  4. 选项B 带权衡
  5. [等待用户反应]
  6. 推荐（仅讨论选项后）

每个选项格式：

### 选项A：[名称]
**方法：** [1句]
**优点：** [要点]
**缺点：** [要点]

你对这个方法的反应是什么？

问题分类

在问任何访谈问题前，分类它：

类型 示例 行动
代码库事实 “存在什么模式？”、“X在哪里？” 先探索，不问用户
用户偏好 “优先级？”、“时间线？” 通过 AskUserQuestion 问用户
范围决策 “包括功能Y？” 问用户
需求 “性能约束？” 问用户

审查质量标准

标准 标准
清晰度 80%+ 声明引用文件/行
可测试性 90%+ 标准具体
验证 所有文件引用存在
特异性 无模糊术语

弃用通知

单独的 /planner、/ralplan 和 /review 技能已合并到 /plan。所有工作流（访谈、直接、共识、审查）都通过 /plan 可用。 </高级>