吾生也有涯，而知也无涯。——庄子

OmX - Oh My codeX（OMX）：你的 Codex 不是一个人在战斗

OMX 的自我介绍很干脆，也很有“人格”：

OmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.

它像一个在你身后随时扶你一把的“战术教练 + 运行时管家”：
不抢 Codex 的方向盘，但把你的驾驶舱升级得更顺手、更稳定、更能跑长任务。

OMX 不是另一个 Codex。
它明确站在 Codex 身边，做一个“工作流层（workflow layer）”：

OMX is a workflow layer for OpenAI Codex CLI.
It keeps Codex as the execution engine…

也就是说——Codex 仍然是那个真正冲向战场、执行工具、写代码、跑命令的执行引擎；
OMX 则像一套“作战条令 + 组织体系 + 仪表盘 + 记事本”，让你从“想到哪做到哪”的临时起意，变成一条从澄清到交付的稳定流水线。

OMX 想解决的不是“能不能做”，而是“怎么稳定做完”

如果你用 Codex 用得越久，你会越懂一个现实：

  • 任务小的时候，Codex 一把梭，非常爽
  • 任务变大、变脏、变长、变复杂的时候，“爽”会变成“散”
    • 你开始反复解释上下文
    • 你开始担心它没按你的流程走
    • 你开始找不到关键决策的记录
    • 你开始缺一个“统一的工作节奏”

这时 OMX 会把椅子拉过来，坐在你旁边，轻轻敲桌子：

  • 先把会话启动得更强
  • 先澄清，再计划
  • 先审批，再执行
  • 需要并行就组队
  • 需要死磕就让一个负责人循环推进到完成

它的核心目标写得很具体：

  • start a stronger Codex session by default
  • run one consistent workflow from clarification to completion
  • invoke the canonical skills with $deep-interview, $ralplan, $team, and $ralph
  • keep project guidance, plans, logs, and state in .omx/

.omx/ 这点很关键：OMX 不只会喊口号，它会把“过程”落到可追踪的状态里——计划、日志、记忆、运行时状态，全都归档在项目里。

推荐默认路径：先把 OMX “点燃”，然后让它带你走主线

如果你想体验 OMX 的“原汁原味默认手感”，它建议你从这里起跑：

1
2
3
npm install -g @openai/codex oh-my-codex
omx setup
omx --madmax --high

这三步就像角色出场三连：

  1. Codex 到位（引擎就绪）
  2. OMX setup 把装备发给你（prompts、skills、config、AGENTS 脚手架）
  3. omx –madmax –high 把会话“启动得更强”，直接进入强势工作态

然后，你在 Codex 里按主线 workflow 走就行：

1
2
3
4
$deep-interview "clarify the authentication change"
$ralplan "approve the auth plan and review tradeoffs"
$ralph "carry the approved plan to completion"
$team 3:executor "execute the approved plan in parallel"

OMX 把这条路称为 main path，并给出一句很像“项目经理定调”的总结：

Start OMX strongly, clarify first when needed, approve the plan, then choose $team for coordinated parallel execution or $ralph for the persistent completion loop.

OMX 适合谁：你已经喜欢 Codex，但想要更好的日常运行时

OMX 并不想把所有人都拉进来，它甚至很坦诚：

If you want plain Codex with no extra workflow layer, you probably do not need OMX.

它适合的是已经用 Codex 开发、并希望获得更强“日常工作流”的人：

  • 想要围绕 $deep-interview、$ralplan、$team、$ralph 的标准流程
  • 想要可复用的 specialist roles 和 supporting skills
  • 想要用 scoped AGENTS.md 做项目��指导
  • 想要 .omx/ 里有耐久状态：plans、logs、memory、mode tracking

OMX 的气质很像“流程型强者”：
它不替你干活，但它让你干活的方式变得更有章法、更可复盘、更不容易丢关键决策。

Quick start：一次“好”的第一局（A good first session）

Requirements

OMX 的门槛写得很清楚：

  • Node.js 20+
  • Codex CLI：npm install -g @openai/codex
  • Codex auth 已配置
  • macOS/Linux 若要 durable team runtime：需要 tmux
  • Windows 原生若要 team mode：需要 psmux

启动（推荐）

1
omx --madmax --high

然后按“经典四连”走：

1
2
3
4
$deep-interview "clarify the authentication change"
$ralplan "approve the safest implementation path"
$ralph "carry the approved plan to completion"
$team 3:executor "execute the approved plan in parallel"

OMX 还贴心地解释了什么时候该用谁：

  • 需要协调并行工作：用 $team
  • 需要一个“持续推进的负责人”把事干到完：用 $ralph

一个简单心智模型：Codex 是引擎，OMX 是更好的“工作层”

OMX 很认真地强调：

OMX does not replace Codex.

它只是给 Codex 外面加了一层更舒服的“工作系统”：

  • Codex：真正执行 agent work 的引擎
  • OMX role keywords：把常用角色变得可复用
  • OMX skills：把常见 workflow 变得可复用
  • .omx/：存 plans、logs、memory、runtime state

它希望你把自己从“每天手动操纵命令面板”的模式里解放出来——
OMX 更像 better task routing + better workflow + better runtime。

新手路线：OMX 亲手把你送上正轨

如果你是第一次用 OMX，它给你的路线是：

  1. omx setup
  2. omx --madmax --high
  3. 不清晰就 $deep-interview "..."（先澄清意图/边界/非目标）
  4. $ralplan "..."（形成并审批实现计划与 tradeoffs）
  5. 然后选：
    • $team：需要多人并行协作
    • $ralph：需要一个 persistent completion loop
  1. $deep-interview — scope 模糊就先澄清
  2. $ralplan — 把澄清后的 scope 变成可审批的架构与实现计划
  3. $team 或 $ralph — 并行 or 持续推进到完成

常见会话入口：四大“台词”，一开口就进入角色

Surface Use it for
$deep-interview "..." clarifying intent, boundaries, and non-goals
$ralplan "..." approving the implementation plan and tradeoffs
$ralph "..." persistent completion and verification loops
$team "..." coordinated parallel execution when the work is big enough
/skills browsing installed skills and supporting helpers

这张表读起来很像在告诉你：
“别吼一大段需求，先用正确的台词，把任务送进正确的轨道。”

高阶操作面：当你真的需要“持久化团队运行时”

OMX 把这些称为 Advanced / operator surfaces，并强调一句：
它们有用，但不是新手上路主线。

Team runtime

当你需要 durable tmux/worktree 协调时，OMX 才建议你上 omx team：

1
2
3
4
omx team 3:executor "fix the failing tests with verification"
omx team status <team-name>
omx team resume <team-name>
omx team shutdown <team-name>

它像一个真的懂工程现场的老手：
团队模式不是为了炫技，而是为了在复杂任务里把并行协作做“可持续、可恢复”。

Setup / Doctor / HUD：OMX 的“后勤与指挥台”

OMX 把自己也当作系统来维护：

  • omx setup：安装 prompts、skills、config、AGENTS scaffolding
  • omx doctor：当你觉得哪里不对劲时，验证安装是否正常
  • omx hud --watch：监控/状态面板（不是主工作流）

OMX 的 HUD 更像驾驶舱仪表盘：
平时别盯着它发呆，但关键时刻它会救命。

Explore & sparkshell：查资料、做验证，别让会话变“失控漫游”

  • omx explore --prompt "..."：用于 只读 的仓库查找
  • omx sparkshell <command>：用于 shell 原生检查与“有边界的验证”

例子很有代表性：

1
2
3
omx explore --prompt "find where team state is written"
omx sparkshell git status
omx sparkshell --tmux-pane %12 --tail-lines 400

它像一个有原则的审计员：
“你可以查，但别破坏；你可以跑命令，但要有边界。”

平台说明：team mode 需要 tmux-compatible backend

OMX 很直接：omx team 需要 tmux 兼容后端。

Platform Install
macOS brew install tmux
Ubuntu/Debian sudo apt install tmux
Fedora sudo dnf install tmux
Arch sudo pacman -S tmux
Windows winget install psmux
Windows (WSL2) sudo apt install tmux

已知问题：Intel Mac 启动时 CPU 飙高（尤其 --madmax --high）

OMX 也会坦白自己的脾气：

在一些 Intel Mac 上，启动时 macOS Gatekeeper 验证大量并发进程会导致 syspolicyd / trustd CPU 飙高。

建议尝试：

  • xattr -dr com.apple.quarantine $(which omx)
  • 把终端加入 macOS Security 的 Developer Tools allowlist
  • 降低并发（避免 --madmax --high）

Autoresearch：OMX 不只是 workflow，它还会“自我优化、做可复现实验”

在 missions/ 与 playground/ 里，OMX 展示了 omx autoresearch 的另一面——
它像一个带着实验习惯的研究员：每个 mission 都有目标、范围、预期交付物，还有 evaluator 合约与安全规则。

Autoresearch pilot missions

你可以直接跑 evaluator：

1
2
3
node scripts/eval-cli-discoverability.js
node scripts/eval-security-path-traversal.js
node scripts/eval-in-action-cat-shellout-demo.js

也可以来一次端到端的真实 run：

1
omx autoresearch missions/in-action-cat-shellout-demo

跑完后去 .omx/logs/autoresearch/<run-id>/ 看它的决策记录（manifest / candidate / iteration ledger），你会看到它如何做 keep/discard/stop。

Autoresearch Research Showcase

playground/ 收集了更小、更可复现的研究型 demo，设计目标是：

  • deterministic 或 seed-controlled
  • 小代码体积
  • 不把大数据集塞进 git
  • 不提交重型运行时产物
  • keep/discard 循环可在 .omx/logs/autoresearch/ 里检查

最经典的运行方式之一：

1
omx autoresearch missions/noisy-bayesopt-highdim

然后查看最近一次 run 的日志：

1
2
3
4
RUN_ID=$(find .omx/logs/autoresearch -maxdepth 1 -mindepth 1 -type d -printf '%f\n' | sort | tail -n 1)
cat .omx/logs/autoresearch/$RUN_ID/manifest.json
cat .omx/logs/autoresearch/$RUN_ID/candidate.json
cat .omx/logs/autoresearch/$RUN_ID/iteration-ledger.json

它像一个很爱写实验记录的人：
“你别只信我说我变强了，你来看证据。”

文档入口：OMX 把地图画好了

  • Getting Started：./docs/getting-started.html
  • Demo guide：./DEMO.md
  • Agent catalog：./docs/agents.html
  • Skills reference：./docs/skills.html
  • Integrations：./docs/integrations.html
  • OpenClaw / notification gateway guide：./docs/openclaw-integration.md
  • Contributing：./CONTRIBUTING.md
  • Changelog：./CHANGELOG.md

并且它还提供多语言 README（包括简体中文 README.zh.md）。

结尾：OMX 的承诺很朴素，但很硬

OMX 不会抢走 Codex 的锋芒。
它只是站在你和 Codex 之间，像一个经验丰富的“工作流搭子”，把每一场开发会话变得更像一场真正的工程执行：

  • 先澄清，再计划
  • 先审批，再开干
  • 需要并行就组队
  • 需要坚持就循环推进
  • 所有过程都留痕在 .omx/

当你对着一个大任务发呆时，OMX 会拍拍你的肩膀：

你的 Codex 不是一个人在战斗。
该上流程了。