OmX 如何用 $ultragoal 跑通多目标工作流从 create-goals 到 checkpoint 与 complete-goals【免费下载链接】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-codexultragoal是 OmXoh-my-codex提供的一个持久化、仓库原生的多目标工作流它叠加在 Codex goal mode 之上长计划保存在.omx/ultragoal/的文件里由 OMX 维护 G001/G002 这样的 story 状态与 ledger 检查点而 Codex goal mode 只负责当前线程的活动目标。本文的任务是在一个 Codex 会话中用omx ultragoal create-goals建立多目标计划反复用omx ultragoal complete-goals启动下一个 story再用omx ultragoal checkpoint记录每个 story 的完成证据直到omx ultragoal status报告所有目标完成。适用环境为 macOS 或 Linux 加 Codex CLIOmX 主要在这条路径上设计和调优Codex CLI 0.128.0 已将goals暴露为启用特性但codex --help里没有goalshell 子命令——goal 能力是以模型工具形式提供给 agent 的。准备安装 OmX 并确认运行时可用按 README.md 的推荐默认流程安装codex --version # 确认已有可用的 Codex CLIHomebrew、npm 均可 npm install -g oh-my-codex如果还没有 Codex CLI 且希望由 npm 管理则先npm install -g openai/codex再安装 OmX。不要对已有的 Homebrewcodex二进制执行合并安装npm install -g openai/codex oh-my-codexnpm 可能在创建同名二进制时报EEXISTOmX 只需要 PATH 上有一个可认证、可工作的codex命令。README 的 Node.js 徽章标注版本要求为 Node ≥ 20。在开始 ultragoal 之前README 要求先做快速冒烟验证omx doctor校验安装形态omx exec证明当前环境的 Codex 运行时确实能完成一次认证与模型调用omx doctor omx exec理解 goal mode 的边界对后面所有步骤都重要见 docs/ultragoal.mdget_goal读取当前线程的活动目标create_goal为一个线程创建一个活动 objective如果线程已有 goal 则会失败update_goal只能把现有 goal 标记为complete。上游 Codex goal 源码还限制 objective 为 4,000 字符并追踪 token/时间用量。OmX 因此不会假装 shell 命令能修改隐藏的 Codex 线程状态omx ultragoal complete-goals只会 checkpoint 仓库状态并打印一段面向模型的 handoff由当前 Codex agent 去安全地调用 goal 工具。用 create-goals 建立多目标计划计划有三种 brief 输入方式--brief内联文本、--brief-file文件、--from-stdin管道以及一个显式的 per-story 分支omx ultragoal create-goals --brief Ship the feature in three safe milestones omx ultragoal create-goals --brief-file docs/my-brief.md cat docs/my-brief.md | omx ultragoal create-goals --from-stdin omx ultragoal create-goals --codex-goal-mode per-story --brief Use one Codex goal context per story--codex-goal-mode per-story是可选分支只有当你明确想要每个 story 一个独立 Codex goal context 时才使用。新计划默认是aggregate Codex goal mode整个 ultragoal run 只有一个 Codex objectiveG001/G002 是 OMX ledger 里的 story。这样避免了同一条线程上从已完成的 G001 Codex goal 切换到新 G002 goal 的不可能迁移。创建成功后三个工件会出现在.omx/ultragoal/下brief.md— 原始 briefgoals.json— 带状态、尝试次数、证据和活动 goal id 的有序持久计划aggregate 模式下还包含codexGoalMode: aggregate和codexObjective——这是发给create_goal的确切 pointer objective完成.omx/ultragoal/goals.json中的持久计划包括后续被接受/追加的 story在原 brief 约束下以.omx/ultragoal/ledger.jsonl作为审计轨迹。它故意不枚举初始G###id这样显式 steering 可以增补或拆分 pending story 而不削弱不可变的目标ledger.jsonl— 只追加的 checkpoint 与 steering 事件plan_created、goal_started、goal_completed、goal_failed等。在 Codex 会话里也可以用$ultragoal ...技能调用同一条工作流例如$ultragoal turn the approved plan into durable Codex goals见 README.md 的推荐流程其底层就是下面这些omx ultragoal子命令。用 complete-goals 启动或续接下一个 storyomx ultragoal complete-goals该命令把下一个 pending 的 OMX story 标记为in_progress向 ledger 追加一条事件并打印 goal-tool handoff。aggregate 模式下的行为是agent 先调用get_goal只有在没有活动 Codex goal 时才调用create_goal如果同一个 aggregate objective 已经处于活动状态agent 直接继续下一个 OMX story不创建新的 Codex goal。complete-goals的别名是complete、next、start-nextcreate-goals的别名是create见 src/cli/ultragoal.ts 的帮助文本。用 checkpoint 记录 story 完成证据checkpoint 是整条工作流里最严格的命令它要求附带你刚取的get_goal快照 JSONOmX 会比较 objective 并按模式强制状态中间 aggregate story 必须是active最终完成必须是complete。中间 story保持 Codex goal 为 active中间 story不要调用update_goal而是用一次新的、objective 与codexObjective匹配且状态仍为active的get_goal快照来 checkpointomx ultragoal checkpoint --goal-id G001-example --status complete --evidence npm test passed; docs updated --codex-goal-json ./get-goal.json几点执行说明G001-example是 docs/ultragoal.md 中的示例 id替换为你计划中真实的 goal id可从omx ultragoal status输出中读取--codex-goal-json接受内联 JSON 或文件路径。get_goal是模型工具而非 shell 命令由 Codex agent 把返回的 JSON 保存成文件如./get-goal.json后再传给该参数在最终 story 之前传入complete状态的快照会被拒绝这是防止提前update_goal的机制。最终 story先过质量门再完成 Codex goal最终 story 有两个层级docs/ultragoal.md 与 src/cli/ultragoal.ts 帮助文本一致普通模式只需要定向验证实现完成的证据加verification命令/证据cleaner、architect、QA 评审通道在普通模式下是 advisory--strict保留 fail-closed 群体门——强制运行最终ai-slop-cleaner、cleaner 后的验证、架构不变量审计和独立$code-review门。强制的最终清理与评审门顺序为对该 story 运行定向验证只对改动文件运行ai-slop-cleaner没有相关编辑时 cleaner 仍运行并记录 passed/no-op 报告cleaner 之后重跑验证运行架构不变量审计从 brief/spec/已接受的 steering/goal 工件中推导不可妥协的架构/领域不变量列出来源工件并用实现、测试、独立评审证据逐一证明每条必需不变量通过独立评审路径运行$code-review。Clean 的判定是codeReview.recommendation: APPROVE、codeReview.architectStatus: CLEAR、codeReview.independentReview包含不同的已完成的code-reviewer与architect子 agent 证据且architectureInvariantGate.status: passed。COMMENT、WATCH、REQUEST CHANGES、BLOCK、缺少子 agent 证据、无法委派、同 lane/自评审、未证明的不变量都算 non-clean若 non-clean不要调用update_goal改用下面的命令记录持久 blocker story若 clean调用update_goal({status: complete})再次调用get_goal然后带--quality-gate-json做最终 checkpoint。评审不 clean 时的记录命令id、objective、findings为占位符替换为当前 story 的真实值最后一个参数是活动的get_goalJSON 或路径omx ultragoal record-review-blockers --goal-id id --title Resolve final code-review blockers --objective blocker-resolution objective --evidence review findings --codex-goal-json active-get-goal-json-or-path该命令把当前 story 标记为review_blocked追加一条 pending 的 blocker-resolution story保持 Codex goal active之后由omx ultragoal complete-goals启动这条 blocker。clean 时的最终 checkpointomx ultragoal checkpoint --goal-id id --status complete --evidence tests/files/review evidence --codex-goal-json fresh-complete-get-goal-json-or-path --quality-gate-json quality-gate-json-or-path--quality-gate-json必须包含 cleaner、verification、codeReview、architectureInvariantGate 四类证据。下面是 docs/ultragoal.md 给出的文档示例结构其中的具体字符串是示例值替换为你本 run 的真实证据{ aiSlopCleaner: { status: passed, evidence: cleaner report }, verification: { status: passed, commands: [npm test], evidence: post-cleaner verification }, codeReview: { recommendation: APPROVE, architectStatus: CLEAR, evidence: final review synthesis, independentReview: { codeReviewer: { agentRole: code-reviewer, evidence: code-reviewer subagent APPROVE evidence }, architect: { agentRole: architect, evidence: architect subagent CLEAR evidence } } }, architectureInvariantGate: { status: passed, sourceArtifacts: [.omx/ultragoal/brief.md, .omx/ultragoal/goals.json], evidence: final invariant audit proved all required architecture/domain invariants, invariants: [ { invariant: Preserve the existing parser boundary., source: .omx/ultragoal/brief.md#architecture-invariants, status: proved, implementationEvidence: changed files preserve the parser boundary, testEvidence: parser-boundary regression passed, reviewEvidence: architect review confirmed the boundary is intact } ] } }legacy 已完成 goal 造成的阻塞--status blocked是非终结的 ledger checkpoint用于两种情况(1) legacy per-story 或 pre-aggregate 会话中一个不同的旧 Codex 线程 goal 已经是complete而当前get_goal/create_goal工具面没有能清掉它的 reset/new-goal 操作(2) 与活动 ultragoal objective 匹配的 Codex goal 真实地blocked需要持久化一条带证据的非终结goal_blocked回执omx ultragoal checkpoint --goal-id G001-example --status blocked --evidence completed legacy Codex goal blocks create_goal in this thread --codex-goal-json ./get-goal.json两种情况都写入goal_blocked事件保持 ultragoal 为in_progress不把它当作完成或失败。处理失败与重试失败处理的命令对omx ultragoal checkpoint --goal-id G001-example --status failed --evidence blocked on missing credential omx ultragoal complete-goals --retry-failed失败的 goal 作为持久化的 retry/blocker 证据留在.omx/ultragoal中本身不是一个活动执行模式。两个值得注意的行为docs/ultragoal.md、src/cli/ultragoal.ts 帮助文本omx status把持久的 failed Ultragoal 计划报告为FAILED而不是ACTIVEHUD 和 state API 阅读器仍可能把 failed goal 暴露为活动未解决的持久工件那个active字段是可见性/生命周期信号不是可取消运行时模式的证明重复出现且相同的外部授权 blocker 会变成不可重试的needs_user_decisionstorycomplete-goals --retry-failed会跳过它们并打印所需的外部决定而不是继续循环——此时停止重试先提供缺失的授权/凭据或显式选择另一条解锁路径。验证整体完成执行循环的判定标准skills/ultragoal/SKILL.md反复执行complete-goals→ 完成一个 story → checkpoint直到omx ultragoal status报告所有目标完成omx ultragoal status omx ultragoal status --json omx ultragoal status --codex-goal-json ./get-goal.jsonstatus会打印总体进度和逐 goal 列表*标记活动 goal。下面是示例输出格式依据 src/cli/ultragoal.ts 的printStatus实现具体 id、标题和数字以你的计划为准ultragoal: 1/3 complete, 1 pending, 1 in progress, 0 failed, 0 review-blocked, 0 needs-user-decision * G002 [in_progress] Implement checkout - G001 [complete] Refactor auth boundary - G003 [pending] Update docs当 aggregate 产品完成时输出首行变为ultragoal aggregate product: complete并附一行仅用于进度的 ledger 记账。若带了--codex-goal-json而快照不匹配例如中间 story 传入了complete快照或 objective 对不上会打印codex goal warning: ...活动或目标错误的 Codex goal 会被当作严格的 mismatch 错误。最后一条纪律来自 docs/ultragoal.mdgoal 不会因为测试通过或存在 ledger 条目就算完成agent 必须用文件、命令、测试、PR 状态或其他具体证据对 objective 做审计不能只凭 OMX 状态宣称完成。限制边界与可选的 steering跑多个顺序 run 时最容易踩的坑是目标清理OmX 故意不调用 Codex 的/goal clearshell 命令和 hooks 也清不掉隐藏的线程 goal 状态。同一条 Codex 线程要开新的 ultragoal run 时先手动在 Codex UI 里执行/goal clear否则get_goal可能仍报告上一个已完成的 aggregate objective下一次同线程create_goal会被阻塞或变得混乱即使 OMX ledger 里的上一个 run 已完成。其他硬约束一条 Codex 线程至多一个 goal focuscreate_goal是启动活动 objective 的工具不是通用计划存储update_goal只用于完成pause/resume/budget 状态由 Codex/用户/系统控制不归 OMX 管中间 aggregate story 的 checkpoint 要求匹配的activeCodex 快照最终 story 要求update_goal({status: complete})之后取的匹配complete快照目前 Codex goal 工具没有 reset/new-goal 面来替换已完成的 legacy 线程 goal。per-story 模式下如果get_goal返回一个不同的已完成 objective 且create_goal因线程已有 goal 而拒绝先用那条get_goalJSON 记录checkpoint --status blocked然后只在同一 branch/worktree 上没有冲突活动/已完成 goal 的 Codex goal context 里create_goalTeam worker 不能执行变更类 ultragoal 命令——ultragoal 状态归 leader 所有worker 只向上报告 checkpoint 证据。如果执行中发现当前子目标分解不再是通往不变 aggregate objective 的最佳路径可以用显式、带证据的 steering 修订分解聚合 Codex objective、原始 brief 约束、质量门和完成状态都不可变steering 不能硬删 goal、自动完成工作或削弱测试/评审omx ultragoal steer --kind add_subgoal --title Investigate blocker --objective Validate the new blocker and report evidence. --evidence log/test output --rationale The blocker changes the safe execution order. --json omx ultragoal steer --directive-json ./steering.json --json允许的 mutation 种类为add_subgoal、split_subgoal、reorder_pending、revise_pending_wording、annotate_ledger、mark_blocked_superseded。宽泛的自然语言请求如“把目标改简单点”会被拒绝而不是猜测被接受和被拒绝的尝试都会向.omx/ultragoal/ledger.jsonl追加结构化审计证据被取代的 goal 保留在goals.json中带 steering 元数据跳过调度但保持审计可见。完成后的下一步同线程再开一个 ultragoal run 之前在 Codex UI 手动执行/goal clear若某个持久 story 需要并行执行通道docs/ultragoal.md 的 “Use Ultragoal and Team together” 一节描述了 leader 在核对 Codex goal 状态后、用 Team 证据做 ultragoal checkpoint 的桥接方式Team 的启动是显式的操作者行为omx ultragoal不会自动拉起 Team持续审计轨迹随时可以在.omx/ultragoal/ledger.jsonl中回查计划状态在.omx/ultragoal/goals.json。【免费下载链接】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），仅供参考
