oh-my-codex Planner 角色深度解析Prometheus 式证据驱动规划工作流【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codexPlannerPrometheus是 oh-my-codexOmX提示词体系中的核心规划角色负责把一条用户请求转化为可执行、有证据支撑的工作计划并只规划、不实现。本文以 prompts/planner.md 为骨架结合 prompt 行为契约、plan 技能与底层规划产物解析源码完整拆解其身份约束、五步执行循环、输出契约、场景处理与 Autopilot 路由逻辑读完即可在 OmX 中正确使用与扩展 Planner 角色。一、Planner 是谁定位、身份与角色边界prompts/planner.md 在文档头部的identity段给出了最精炼的角色定义You are Planner (Prometheus). Turn a request into an actionable, evidence-grounded work plan. You plan and hand off; you do not implement code.这句话包含三个关键断言代号 PrometheusPlanner 在 OmX 角色目录中是可安装的专业化 Agent 之一属于协调/构建链路的前置规划角色产出物是可执行且有证据支撑的计划actionable, evidence-grounded work plan而非泛泛的方案描述规划并交接绝不实现代码plan and hand off; you do not implement code这是与 Executor 最根本的分工边界。在源码侧Planner 的角色元数据定义在 src/agents/definitions.tsplanner: { name: planner, description: Task sequencing, execution plans, risk flags, reasoningEffort: medium, exactModel: gpt-5.6-sol, posture: frontier-orchestrator, modelClass: frontier, routingRole: leader, tools: analysis, category: build, },可以从中提炼出 Planner 的角色画像默认推理强度 medium、可精确钉到gpt-5.6-sol模型、姿态为前端编排者frontier-orchestrator、路由角色是 leader而非 executor、工具面为分析型analysis、归属 build 分类。提示词正文在运行时从prompts/目录加载definitions.ts只负责元数据二者解耦——这正符合 docs/prompt-guidance-contract.md 中行为契约与路由元数据分离的设计原则。二、约束清单写到哪里、问什么、规划多大constraints段定义了 Planner 不可逾越的行为边界共六条产物路径固定计划只写入.omx/plans/*.md草稿使用.omx/drafts/*.md自查优先仓库事实必须由 Planner 自己检查Inspect repository facts yourself只允许就优先级、取舍、决策发问且必须是检查无法自行消解的问题规模与请求成正比步骤数量与范围要匹配请求禁止顺带重设计无关架构do not redesign unrelated architecture计划必备要素每份计划必须点名受影响资源affected resources、验收标准acceptance criteria、风险risks、验证verification与交接指引handoff guidance非请求不落地除非用户明确要求规划、或当前规划工作流要求否则不要定稿计划Do not finalize a plan until the user clearly requests planning...两个OMX:GUIDANCE:PLANNER:CONSTRAINTS哨兵标记包裹的指引块对应仓库中的 docs/prompt-guidance-fragments/planner-constraints.md要求使用 outcome-first、可直接执行的计划定义期望结果、成功标准、约束、证据、验证路径与停止条件规划更新保持简短直接只浮出会实质改变计划的关键决策把更新的用户指令视为当前规划分支的局部覆盖local override同时保留无关的既有验收标准计划扎根于仓库证据每个提议步骤都必须可执行。这些约束在存储层有对应实现规划产物解析逻辑位于 src/planning/artifacts.ts其中readPlanningArtifacts会把工作目录下的.omx/plans与.omx/specs作为规划的唯二事实源按文件名模式扫描三类产物const plansDir join(cwd, .omx, plans); const specsDir join(cwd, .omx, specs); // prdPaths: .omx/plans/prd-*.md // testSpecPaths: .omx/plans/test-spec-*.md / test-spec-*.md // deepInterviewSpecPaths: .omx/specs/deep-interview-*.md而规划是否完成的判定isPlanningComplete是必须同时存在 PRD 与至少一个匹配的测试规格文件Boolean(selection.prdPath) selection.testSpecPaths.length 0——这正是约束第 4 条验收标准可测的落地体现。三、执行循环五步规划方法论execution_loop段给出了 Planner 的标准工作流共五步先检查仓库并对请求分类Inspect the repository and classify the request before asking about code facts——在询问任何代码事实之前必须先做仓库检查抽取要素范围scope、约束、依赖、文件引用、失败行为failure behavior、验收目标只消解真正的偏好/取舍问题其余情况选择最小自洽路径smallest coherent path起草规模得当的计划包含有序步骤、风险、缓解措施和可直接执行的验证命令direct verification commands定稿校验确认被引用的文件确实存在、交接无需猜测然后保存计划产物。OMX:GUIDANCE:PLANNER:INVESTIGATION哨兵块进一步要求Keep inspecting referenced code, tests, documentation, and other evidence until requirements, affected resources, validation commands, failure behavior, and material open questions are traceable.即持续检查被引用的代码、测试、文档与证据直到需求、受影响资源、验证命令、失败行为与实质性开放问题全部可追溯traceable。这与 docs/prompt-guidance-contract.md 中证据预算evidence budgets原则一致——继续检索与验证的前提是正确性依赖仓库检视、官方文档或测试证据而非无意义的追加循环。四、输出契约outcome-first 的计划模板output_contract是 Planner 最可直接落地的部分它定义了最终输出的固定结构Plan Summary**Plan saved to:** .omx/plans/{name}.md **Scope:** [tasks] across [files]; estimated complexity: LOW / MEDIUM / HIGH.Requirements and Acceptance- Requirements: [observable requirements] - Acceptance criteria: [specific, testable conditions]Implementation Steps1. [Step with file/resource references and dependencies] 2. [Additional steps required by scope]Risks and Verification- Risks / mitigations: [concrete items] - Verification: [commands or evidence that prove each criterion] - Stop condition: [what permits completion or what blocks it]OMX:GUIDANCE:PLANNER:OUTPUT哨兵块一句话概括了这套结构的本质Default final-output shape: outcome-first and execution-ready, mapping requirements to files/resources, validation checks, risks, stop rules, and the next handoff.即默认输出形态是结果优先、可执行就绪把需求映射到文件/资源、验证检查、风险、停止规则与下一步交接。这套模板在运行层有完整的读取与校验配套。文件命名规范定义在 src/planning/artifact-names.tsPRDprd-{slug}.md或带时间戳的prd-{timestamp}-{slug}.md时间戳形如20260911T000000Z测试规格test-spec-{slug}.md若 PRD 带时间戳则必须匹配test-spec-{timestamp}-{slug}.md见requiredTimestampedTestSpecFileName深度访谈规格deep-interview-{slug}.md另有deep-interview-autoresearch-{slug}.md变体存放在.omx/specs/。而 src/planning/artifacts.ts 中的readApprovedExecutionLaunchHint会从已批准的计划文本里解析omx team N:role task/omx ralph task启动提示launch hint供下游 team/ralph 模式直接续接执行——这解释了模板里**Plan saved to:** .omx/plans/{name}.md一行的真实用途计划不是写完就结束的文档而是团队执行、ralph 执行的可解析交接媒介。五、场景处理continue / make a PR / merge if CI greenscenario_handling段针对三种高频用户指令给出了明确的语义约定防止 Planner 误把执行上下文当作规划证据用户指令正确行为continue继续当前规划分支current planning branch补足缺失证据而不是重启规划make a PR视为下游执行上下文downstream execution context计划仍聚焦其验收标准merge if CI green视为下一个操作步骤上的带条件约束scoped condition不是计划证据这套约定正是 docs/prompt-guidance-contract.md 中局部化任务更新覆盖Localized task-update overrides模式的场景化落地更新的用户指令是活动任务的局部覆盖同时保留先前不冲突的指令。对应片段在 docs/prompt-guidance-fragments/planner-shared.md 中表述为Treat newer user task updates as local overrides for the active planning branch while preserving earlier non-conflicting constraints.六、与 plan 技能配合Interview / Direct / Review 三模式Planner 角色提示词与 skills/plan/SKILL.md 技能是一体两面角色提示词定义怎么思考技能定义何时调用、以什么模式调用。plan 技能支持三种模式模式触发方式行为Interview--interview或需求宽泛Socratic 式需求澄清一次只问一个问题Direct--direct或需求已详细立即生成计划Review--review对既有计划做批判性评审Interview 模式的执行要点先对请求分类通过omx question一次只问一个聚焦问题先收集代码库事实再做有依据的追问gather codebase facts first, then ask informed follow-ups基于回答推进可让 Analyst 挖掘隐藏需求用户示意就绪后生成计划。Review 模式则读取.omx/plans/下的计划交给 Critic 给出 APPROVED / REVISE / REJECT 结论若评审者与作者是同一角色则转交$code-review。技能还给出了明确的退出条件Escalation and Stop Conditions需求已清晰就停止访谈不要过度访谈do not over-interview遇到需要业务决策的不可调和取舍时升级用户说 just do it / skip planning 时交接给$ultragoal。最终检查清单Final Checklist与输出契约呼应验收标准可测90% 具体可验证断言带文件/行号引用80%风险有缓解措施无含糊术语计划已保存到.omx/plans/七、Planner 在 Autopilot 路由中的位置规划权并不总是落在 Planner 角色上src/autopilot/planner-routing.ts 的resolveAutopilotPlannerRouting决定 Autopilot 模式下重规划由谁主导explicit_planner_override维护者显式配置了agentModels.planner覆盖 → 规划权归 Plannermain_is_cheap_or_mini主模型被识别为经济/迷你模型匹配mini|nano|small|cheap|economy|spark|luna|lite|flash等模式见isCheapOrMiniModelName→ 规划权归 Planner避免草拟/分解阶段停留在廉价车道main_not_cheap_or_mini主模型足够强且无显式覆盖 → 规划留在主模型上向后兼容。默认 Planner 模型的解析链getDefaultPlannerModel为getAgentModelOverride(planner)→AGENT_DEFINITIONS.planner.exactModel即gpt-5.6-sol→ 主默认模型。这意味着 Planner 角色的模型钉选exactModel pin在团队运行时同样生效与 src/agents/definitions.ts 中的定义保持一致。八、行为契约GPT-5.6 Prompt Guidance 下的 Planner 写作规范Planner 提示词不是孤立文件它受 docs/prompt-guidance-contract.md 描述的 OmX 全局行为契约约束。契约中的五个核心模式five core patterns对 Planner 的具体要求如下Outcome-first、成功标准驱动先描述目标结果、成功标准、约束、可用证据、期望输出与停止条件再加过程细节简洁协作风格 长任务前言多步/工具密集任务开始时给出简短可见的前言点明请求并命名第一步低风险下一步自动跟进对清晰、低风险、可逆的步骤自动继续只为不可逆、凭据门槛、外部生产、破坏性或实质改变范围的动作提问局部覆盖而非整体重置见上文场景处理部分证据预算与显式停止规则继续检索/验证的前提是正确性依赖仓库检视、官方文档、诊断或测试计划必须保持可追溯——需求、命名文件/资源/API、状态迁移、验证命令、失败行为与实质性开放问题都需列明。契约中还有两条对 Planner 特别相关的硬性规则绝对语言规则Absolute-language ruleMUST、NEVER、ALWAYS、only等绝对措辞只能用于真正的恒常不变量——安全/安全边界、副作用约束、必需输出字段、工作流状态迁移、团队/ralph 门禁与产品契约对是否再搜一次、是否澄清、是否继续迭代这类判断优先给决策规则与停止条件而非绝对命令活动工作流终态交接契约Terminal handoff contract终态回复必须命名明确结局如finished、blocked、failed、userinterlude、askuserQuestion附带支撑该结局的证据或阻塞原因明确交接对象且不得以If you want, I can...之类的征求许可软语结尾。九、实操把一条请求变成合格计划综合角色提示词、plan 技能与源码约束一次正确的 Planner 会话应走完以下闭环先查后问打开仓库、读取被引用文件与测试完成请求分类代码库事实类问题绝不问用户见 skills/plan/SKILL.md 的问题分类表一次一问确有偏好/取舍类问题时通过omx question一次只问一个按模板落盘把计划按 Plan Summary / Requirements and Acceptance / Implementation Steps / Risks and Verification 四段结构写入.omx/plans/prd-{name}.md并确保引用的文件真实存在配对测试规格按test-spec-{name}.mdPRD 带时间戳时使用同时间戳前缀补齐验收映射使isPlanningComplete判定为真参考 src/planning/artifacts.ts必要时评审需要把关时以--review模式交给 Critic得到 APPROVED / REVISE / REJECT 之一作者与评审者相同时转$code-review明确交接若计划获批且包含omx team/omx ralph启动提示运行层可通过readApprovedExecutionLaunchHint直接解析出交接命令无需人工猜测参考 src/planning/artifacts.ts。十、小结PlannerPrometheus在 OmX 中的价值在于证据驱动的规划纪律它把一次请求拆解为有明确产出物.omx/plans/下的 PRD 测试规格、明确验收可测标准、明确风险含缓解措施与明确交接team/ralph 启动提示的计划闭环。无论你是想理解 OmX 的规划角色如何工作还是想按 docs/prompt-guidance-contract.md 扩展自己的 Planner 提示词都可以以 prompts/planner.md 为起点配合 docs/prompt-guidance-fragments/planner-shared.md、skills/plan/SKILL.md 与 src/planning/artifacts.ts 逐层验证即可完整复现这套从请求到可执行计划的工程化流程。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-codex Planner 角色深度解析：Prometheus 式证据驱动规划工作流
oh-my-codex Planner 角色深度解析Prometheus 式证据驱动规划工作流【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codexPlannerPrometheus是 oh-my-codexOmX提示词体系中的核心规划角色负责把一条用户请求转化为可执行、有证据支撑的工作计划并只规划、不实现。本文以 prompts/planner.md 为骨架结合 prompt 行为契约、plan 技能与底层规划产物解析源码完整拆解其身份约束、五步执行循环、输出契约、场景处理与 Autopilot 路由逻辑读完即可在 OmX 中正确使用与扩展 Planner 角色。一、Planner 是谁定位、身份与角色边界prompts/planner.md 在文档头部的identity段给出了最精炼的角色定义You are Planner (Prometheus). Turn a request into an actionable, evidence-grounded work plan. You plan and hand off; you do not implement code.这句话包含三个关键断言代号 PrometheusPlanner 在 OmX 角色目录中是可安装的专业化 Agent 之一属于协调/构建链路的前置规划角色产出物是可执行且有证据支撑的计划actionable, evidence-grounded work plan而非泛泛的方案描述规划并交接绝不实现代码plan and hand off; you do not implement code这是与 Executor 最根本的分工边界。在源码侧Planner 的角色元数据定义在 src/agents/definitions.tsplanner: { name: planner, description: Task sequencing, execution plans, risk flags, reasoningEffort: medium, exactModel: gpt-5.6-sol, posture: frontier-orchestrator, modelClass: frontier, routingRole: leader, tools: analysis, category: build, },可以从中提炼出 Planner 的角色画像默认推理强度 medium、可精确钉到gpt-5.6-sol模型、姿态为前端编排者frontier-orchestrator、路由角色是 leader而非 executor、工具面为分析型analysis、归属 build 分类。提示词正文在运行时从prompts/目录加载definitions.ts只负责元数据二者解耦——这正符合 docs/prompt-guidance-contract.md 中行为契约与路由元数据分离的设计原则。二、约束清单写到哪里、问什么、规划多大constraints段定义了 Planner 不可逾越的行为边界共六条产物路径固定计划只写入.omx/plans/*.md草稿使用.omx/drafts/*.md自查优先仓库事实必须由 Planner 自己检查Inspect repository facts yourself只允许就优先级、取舍、决策发问且必须是检查无法自行消解的问题规模与请求成正比步骤数量与范围要匹配请求禁止顺带重设计无关架构do not redesign unrelated architecture计划必备要素每份计划必须点名受影响资源affected resources、验收标准acceptance criteria、风险risks、验证verification与交接指引handoff guidance非请求不落地除非用户明确要求规划、或当前规划工作流要求否则不要定稿计划Do not finalize a plan until the user clearly requests planning...两个OMX:GUIDANCE:PLANNER:CONSTRAINTS哨兵标记包裹的指引块对应仓库中的 docs/prompt-guidance-fragments/planner-constraints.md要求使用 outcome-first、可直接执行的计划定义期望结果、成功标准、约束、证据、验证路径与停止条件规划更新保持简短直接只浮出会实质改变计划的关键决策把更新的用户指令视为当前规划分支的局部覆盖local override同时保留无关的既有验收标准计划扎根于仓库证据每个提议步骤都必须可执行。这些约束在存储层有对应实现规划产物解析逻辑位于 src/planning/artifacts.ts其中readPlanningArtifacts会把工作目录下的.omx/plans与.omx/specs作为规划的唯二事实源按文件名模式扫描三类产物const plansDir join(cwd, .omx, plans); const specsDir join(cwd, .omx, specs); // prdPaths: .omx/plans/prd-*.md // testSpecPaths: .omx/plans/test-spec-*.md / test-spec-*.md // deepInterviewSpecPaths: .omx/specs/deep-interview-*.md而规划是否完成的判定isPlanningComplete是必须同时存在 PRD 与至少一个匹配的测试规格文件Boolean(selection.prdPath) selection.testSpecPaths.length 0——这正是约束第 4 条验收标准可测的落地体现。三、执行循环五步规划方法论execution_loop段给出了 Planner 的标准工作流共五步先检查仓库并对请求分类Inspect the repository and classify the request before asking about code facts——在询问任何代码事实之前必须先做仓库检查抽取要素范围scope、约束、依赖、文件引用、失败行为failure behavior、验收目标只消解真正的偏好/取舍问题其余情况选择最小自洽路径smallest coherent path起草规模得当的计划包含有序步骤、风险、缓解措施和可直接执行的验证命令direct verification commands定稿校验确认被引用的文件确实存在、交接无需猜测然后保存计划产物。OMX:GUIDANCE:PLANNER:INVESTIGATION哨兵块进一步要求Keep inspecting referenced code, tests, documentation, and other evidence until requirements, affected resources, validation commands, failure behavior, and material open questions are traceable.即持续检查被引用的代码、测试、文档与证据直到需求、受影响资源、验证命令、失败行为与实质性开放问题全部可追溯traceable。这与 docs/prompt-guidance-contract.md 中证据预算evidence budgets原则一致——继续检索与验证的前提是正确性依赖仓库检视、官方文档或测试证据而非无意义的追加循环。四、输出契约outcome-first 的计划模板output_contract是 Planner 最可直接落地的部分它定义了最终输出的固定结构Plan Summary**Plan saved to:** .omx/plans/{name}.md **Scope:** [tasks] across [files]; estimated complexity: LOW / MEDIUM / HIGH.Requirements and Acceptance- Requirements: [observable requirements] - Acceptance criteria: [specific, testable conditions]Implementation Steps1. [Step with file/resource references and dependencies] 2. [Additional steps required by scope]Risks and Verification- Risks / mitigations: [concrete items] - Verification: [commands or evidence that prove each criterion] - Stop condition: [what permits completion or what blocks it]OMX:GUIDANCE:PLANNER:OUTPUT哨兵块一句话概括了这套结构的本质Default final-output shape: outcome-first and execution-ready, mapping requirements to files/resources, validation checks, risks, stop rules, and the next handoff.即默认输出形态是结果优先、可执行就绪把需求映射到文件/资源、验证检查、风险、停止规则与下一步交接。这套模板在运行层有完整的读取与校验配套。文件命名规范定义在 src/planning/artifact-names.tsPRDprd-{slug}.md或带时间戳的prd-{timestamp}-{slug}.md时间戳形如20260911T000000Z测试规格test-spec-{slug}.md若 PRD 带时间戳则必须匹配test-spec-{timestamp}-{slug}.md见requiredTimestampedTestSpecFileName深度访谈规格deep-interview-{slug}.md另有deep-interview-autoresearch-{slug}.md变体存放在.omx/specs/。而 src/planning/artifacts.ts 中的readApprovedExecutionLaunchHint会从已批准的计划文本里解析omx team N:role task/omx ralph task启动提示launch hint供下游 team/ralph 模式直接续接执行——这解释了模板里**Plan saved to:** .omx/plans/{name}.md一行的真实用途计划不是写完就结束的文档而是团队执行、ralph 执行的可解析交接媒介。五、场景处理continue / make a PR / merge if CI greenscenario_handling段针对三种高频用户指令给出了明确的语义约定防止 Planner 误把执行上下文当作规划证据用户指令正确行为continue继续当前规划分支current planning branch补足缺失证据而不是重启规划make a PR视为下游执行上下文downstream execution context计划仍聚焦其验收标准merge if CI green视为下一个操作步骤上的带条件约束scoped condition不是计划证据这套约定正是 docs/prompt-guidance-contract.md 中局部化任务更新覆盖Localized task-update overrides模式的场景化落地更新的用户指令是活动任务的局部覆盖同时保留先前不冲突的指令。对应片段在 docs/prompt-guidance-fragments/planner-shared.md 中表述为Treat newer user task updates as local overrides for the active planning branch while preserving earlier non-conflicting constraints.六、与 plan 技能配合Interview / Direct / Review 三模式Planner 角色提示词与 skills/plan/SKILL.md 技能是一体两面角色提示词定义怎么思考技能定义何时调用、以什么模式调用。plan 技能支持三种模式模式触发方式行为Interview--interview或需求宽泛Socratic 式需求澄清一次只问一个问题Direct--direct或需求已详细立即生成计划Review--review对既有计划做批判性评审Interview 模式的执行要点先对请求分类通过omx question一次只问一个聚焦问题先收集代码库事实再做有依据的追问gather codebase facts first, then ask informed follow-ups基于回答推进可让 Analyst 挖掘隐藏需求用户示意就绪后生成计划。Review 模式则读取.omx/plans/下的计划交给 Critic 给出 APPROVED / REVISE / REJECT 结论若评审者与作者是同一角色则转交$code-review。技能还给出了明确的退出条件Escalation and Stop Conditions需求已清晰就停止访谈不要过度访谈do not over-interview遇到需要业务决策的不可调和取舍时升级用户说 just do it / skip planning 时交接给$ultragoal。最终检查清单Final Checklist与输出契约呼应验收标准可测90% 具体可验证断言带文件/行号引用80%风险有缓解措施无含糊术语计划已保存到.omx/plans/七、Planner 在 Autopilot 路由中的位置规划权并不总是落在 Planner 角色上src/autopilot/planner-routing.ts 的resolveAutopilotPlannerRouting决定 Autopilot 模式下重规划由谁主导explicit_planner_override维护者显式配置了agentModels.planner覆盖 → 规划权归 Plannermain_is_cheap_or_mini主模型被识别为经济/迷你模型匹配mini|nano|small|cheap|economy|spark|luna|lite|flash等模式见isCheapOrMiniModelName→ 规划权归 Planner避免草拟/分解阶段停留在廉价车道main_not_cheap_or_mini主模型足够强且无显式覆盖 → 规划留在主模型上向后兼容。默认 Planner 模型的解析链getDefaultPlannerModel为getAgentModelOverride(planner)→AGENT_DEFINITIONS.planner.exactModel即gpt-5.6-sol→ 主默认模型。这意味着 Planner 角色的模型钉选exactModel pin在团队运行时同样生效与 src/agents/definitions.ts 中的定义保持一致。八、行为契约GPT-5.6 Prompt Guidance 下的 Planner 写作规范Planner 提示词不是孤立文件它受 docs/prompt-guidance-contract.md 描述的 OmX 全局行为契约约束。契约中的五个核心模式five core patterns对 Planner 的具体要求如下Outcome-first、成功标准驱动先描述目标结果、成功标准、约束、可用证据、期望输出与停止条件再加过程细节简洁协作风格 长任务前言多步/工具密集任务开始时给出简短可见的前言点明请求并命名第一步低风险下一步自动跟进对清晰、低风险、可逆的步骤自动继续只为不可逆、凭据门槛、外部生产、破坏性或实质改变范围的动作提问局部覆盖而非整体重置见上文场景处理部分证据预算与显式停止规则继续检索/验证的前提是正确性依赖仓库检视、官方文档、诊断或测试计划必须保持可追溯——需求、命名文件/资源/API、状态迁移、验证命令、失败行为与实质性开放问题都需列明。契约中还有两条对 Planner 特别相关的硬性规则绝对语言规则Absolute-language ruleMUST、NEVER、ALWAYS、only等绝对措辞只能用于真正的恒常不变量——安全/安全边界、副作用约束、必需输出字段、工作流状态迁移、团队/ralph 门禁与产品契约对是否再搜一次、是否澄清、是否继续迭代这类判断优先给决策规则与停止条件而非绝对命令活动工作流终态交接契约Terminal handoff contract终态回复必须命名明确结局如finished、blocked、failed、userinterlude、askuserQuestion附带支撑该结局的证据或阻塞原因明确交接对象且不得以If you want, I can...之类的征求许可软语结尾。九、实操把一条请求变成合格计划综合角色提示词、plan 技能与源码约束一次正确的 Planner 会话应走完以下闭环先查后问打开仓库、读取被引用文件与测试完成请求分类代码库事实类问题绝不问用户见 skills/plan/SKILL.md 的问题分类表一次一问确有偏好/取舍类问题时通过omx question一次只问一个按模板落盘把计划按 Plan Summary / Requirements and Acceptance / Implementation Steps / Risks and Verification 四段结构写入.omx/plans/prd-{name}.md并确保引用的文件真实存在配对测试规格按test-spec-{name}.mdPRD 带时间戳时使用同时间戳前缀补齐验收映射使isPlanningComplete判定为真参考 src/planning/artifacts.ts必要时评审需要把关时以--review模式交给 Critic得到 APPROVED / REVISE / REJECT 之一作者与评审者相同时转$code-review明确交接若计划获批且包含omx team/omx ralph启动提示运行层可通过readApprovedExecutionLaunchHint直接解析出交接命令无需人工猜测参考 src/planning/artifacts.ts。十、小结PlannerPrometheus在 OmX 中的价值在于证据驱动的规划纪律它把一次请求拆解为有明确产出物.omx/plans/下的 PRD 测试规格、明确验收可测标准、明确风险含缓解措施与明确交接team/ralph 启动提示的计划闭环。无论你是想理解 OmX 的规划角色如何工作还是想按 docs/prompt-guidance-contract.md 扩展自己的 Planner 提示词都可以以 prompts/planner.md 为起点配合 docs/prompt-guidance-fragments/planner-shared.md、skills/plan/SKILL.md 与 src/planning/artifacts.ts 逐层验证即可完整复现这套从请求到可执行计划的工程化流程。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考