omc

omc — 面向 Claude 的拓扑感知型 oh-my-claudecode 路由器

何时使用此技能

• 用户希望通过 OMC / oh-my-claudecode 实现 原生 Claude Code 编排
• 用户需要在 市场插件、omc shell CLI 或 本地检出 / --plugin-dir 工作流之间做出选择
• 用户询问 /team、/autopilot、/ralph、/ultrawork、/ultraqa、omc team、omc ask、omc setup、omc update、钩子、HUD 或 OMC 状态行为
• 用户询问如何将 /team、/autopilot、/ultrawork 或 /ultraqa 等 Claude 工作流映射到 Codex/OMX 或 Gemini/Antigravity/OMA
• 用户遇到 重复安装、plugin-dir 混淆、工作树 / 状态冲突、设置漂移 或 HUD / 速率限制 / 恢复问题
• 用户真正需要的是 以 Claude 为先的运行时管理器，而不是 jeo、ralphmode、omx、ohmg 或浏览器审查技能

说明

第 1 步：在给出命令前确定安装拓扑

在建议命令之前，先确认操作者实际使用的是哪种 OMC 拓扑：

1. 市场插件 — 从市场安装的 Claude Code 插件 / 斜杠技能界面
2. shell-cli — 通过 npm 安装的 omc 命令，用于 shell 侧设置、tmux 工作进程或提供方咨询
3. 本地插件目录 — 本地检出 / --plugin-dir / OMC_PLUGIN_ROOT 工作流
4. 混合或未知 — 插件、CLI 与本地检出重叠，存在重复命令，或设置状态不明确

如果拓扑为 mixed-or-unknown，应优先进行恢复和拓扑澄清，然后再建议更多命令。

第 2 步：选择一个请求类别

拓扑足够明确后，将实际任务归入一个类别：

1. 安装拓扑 — 安装、首次运行设置，或本地检出 / 插件目录决策
2. 会话内运行时 — 在 Claude Code 中选择合适的斜杠技能
3. 终端运行时 — 选择合适的 omc ... shell 命令
4. 恢复与更新 — 修复重复安装、设置漂移、工作树 / 状态问题、HUD / 钩子或恢复问题
5. 跨运行时对等映射 — 将 Claude 斜杠工作流映射到 OMX 或 OMA，但不要假装这些运行时完全相同
6. 边界与转交 — 请求实际属于 jeo、ralphmode、plannotator、浏览器审查技能或其他运行时

先在心里确定拓扑和请求类别，再只提供与该组合相符的命令。

第 3 步：告知操作者当前使用的界面

OMC 有 两个实际运行时界面。不要将它们混为一谈。

A. Claude Code 插件 / 会话内界面

当用户已在 Claude Code 内，并需要斜杠技能、钩子、HUD 或原生团队行为时使用。

示例：

/team 3:executor "fix all TypeScript errors"
/autopilot "build a REST API for tasks"
/ralph "keep going until verified done"
/ultrawork "parallelize this cleanup"
/deep-interview "help me clarify the feature"

此界面负责：

• 斜杠技能
• 钩子和 HUD 行为
• Claude Code 内的原生团队编排
• autopilot: 或 ralph: 等会话内关键词

B. 终端 CLI 界面

当用户需要 shell 侧设置、更新、提供方咨询、tmux 工作进程或运行时管理时使用。

示例：

omc setup
omc update
omc ask codex "review this patch"
omc team 2:codex "review auth flow"
omc team status review-auth-flow

此界面负责：

• omc setup / omc update
• omc ask
• omc team tmux 工作进程
• shell 侧运行时管理

重要事实：

• /team 和 omc team 是 不同的运行时
• /autopilot、/ralph 和 /ultrawork 是 会话内技能，不是常规的 omc CLI 子命令
• npm 包名是 oh-my-claude-sisyphus，不是 oh-my-claudecode

第 4 步：使用正确的拓扑 + 请求类别组合

数据包：安装拓扑

当用户需要安装、设置或清理拓扑时使用。

marketplace-plugin

在 Claude Code 中：

/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
/plugin install oh-my-claudecode

然后在 Claude Code 中运行一个设置入口：

setup omc

或：

/oh-my-claudecode:omc-setup

shell-cli

如果他们还想使用 omc shell 命令：

npm i -g oh-my-claude-sisyphus@latest

local-plugin-dir

不要假装 marketplace 流程就足够了。在自行尝试清理之前，先引导他们使用 plugin-dir / local-checkout 路径和专用参考文档：

• omc --plugin-dir <path> ...
• OMC_PLUGIN_ROOT
• omc setup --plugin-dir-mode
• references/install-topology-and-recovery.md

mixed-or-unknown

将重复命令、重复斜杠技能或状态不明确的情况首先视为恢复问题。不要在拓扑不明确时继续叠加安装。

当预期使用 Claude 原生团队时，在 ~/.claude/settings.json 中启用原生团队：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

数据包：会话内运行时

当用户想为任务选择最佳的 Claude Code 斜杠技能 时使用。

需求	使用	原因
会话内共享多 Agent 协作	/team ...	标准的 Claude 原生团队工作流
根据模糊请求端到端构建	/autopilot ... 或 autopilot: ...	单个主 Agent，贯穿构思 → 实现
必须持续执行，直到验证完成	/ralph ... 或 ralph: ...	持续执行 → 验证 → 修复循环
突发并行工作	/ultrawork ... 或 ulw ...	高并行度，无需完整团队的开销
并行 QA / 评审突发任务	已安装时使用 /ultraqa ...	QA 扇出；目标运行时不是 Claude 时，路由至 OMX $ultraqa 或 OMA /review
先澄清需求	/deep-interview ...	在规划或执行前先澄清
跨模型综合	上游 / 运行时支持时使用 ccg: ...	咨询式综合路径

选择一个准确的推荐方案，最多再提供一个相近的替代方案。

数据包：终端运行时

当用户想使用 shell CLI，而不是会话内插件界面时使用。

需求	使用
首次安装 / 修复 shell 端	omc setup
更新后刷新	omc update
咨询提供方	omc ask <provider> "..."
基于 tmux 的工作器团队	omc team <N>:<provider> "<task>"
团队运行时状态	omc team status <session>
关闭团队运行时	omc team shutdown <session>

如果用户说“团队模式”，但当前已在 Claude Code 中，优先使用 /team。 如果用户说“团队模式”，且明确想使用 shell / tmux 工作器，优先使用 omc team。

数据包：跨运行时兼容

当用户希望 Claude OMC 工作流也能在 Codex 或 Antigravity 中使用时使用。阅读 references/cross-runtime-workflow-map.md，然后按意图进行映射：

Claude / OMC	Codex / OMX	Gemini / Antigravity / OMA
/team N:role "task"	$team N:role "task" 或 omx team N:role "task"	/orchestrate "task" 或 oma agent:parallel -i role:"task"
/autopilot "task" 或 autopilot: task	$autopilot "task"；对于含糊的请求，先使用 $deep-interview；或使用 $plan → $ralph 进行更严格的验证	/plan "task" → /work；只有在明确需要并行任务通道时，才使用 /orchestrate 或 oma agent:parallel
/ultrawork "task" / ulw "task"	$ulw "task" 或 $ultrawork "task"	/ultrawork "task"；对于独立任务通道，使用 oma agent:parallel
/ultraqa "target"	$ultraqa "target"	/review "target" 或 /ultrawork "QA target"；对于明确的 QA 任务通道，使用 oma agent:parallel

规则：

• 首先说明运行时边界：OMC 使用 .omc/，OMX 使用 .omx/，OMA 将 .agents/ 作为规范目录。
• 将 /autopilot 视为意图约定，而非通用命令名称：Codex 使用 $autopilot；OMA 通常组合使用 /plan 和 /work。
• 不要声称 Antigravity 支持 Claude 风格的自定义子 Agent 派生；需要时使用 OMA CLI 作为后备方案。
• 目标为 Codex 原生环境时，将操作细节转交给 omx。
• 目标为 Gemini/Antigravity 便携式工具框架工作时，将操作细节转交给 ohmg。

数据包：恢复与更新

当实际任务是修复 OMC 时使用。

主要恢复模式：

• 重复安装 / 命令重复 → 检查 marketplace 插件、npm CLI 和本地检出/插件目录安装是否相互重叠
• 升级后配置漂移 → 针对当前拓扑重新执行正确的设置/更新流程（setup omc、/oh-my-claudecode:omc-setup、omc update、omc setup）
• 本地检出的行为与 marketplace 安装不一致 → 检查 --plugin-dir、OMC_PLUGIN_ROOT 和插件目录模式，而不是盲目重新安装
• 团队模式无法使用 → 确认 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• Worktree/状态异常 → 检查 .omc/state/、worktree 命名空间行为以及团队/会话名称
• HUD / 速率限制 / 临时环境问题 → 将其视为环境/运行时恢复问题，而非模式选择问题

需要详细修复步骤时，转到：

• references/install-topology-and-recovery.md
• references/intake-packets-and-route-outs.md
• references/cli-reference.md
• references/hooks-reference.md

数据包：边界与转交

如果其他技能更适合处理任务，不要强行使用 OMC。

以下情况应转交：

• 长期计划 / 执行记录 / 可恢复的多技能循环 → jeo
• 超出 OMC 运行时细节的规范优先持久化方法 → ralph
• 审批策略、受信任文件夹 / 绕过策略、权限范围 → ralphmode
• 计划审查 / 审批关卡 → plannotator
• 新会话中的浏览器验证 → browser-harness
• 复用正在运行且已通过身份验证的浏览器 → playwriter
• 精确的渲染 UI 评审 / 注释交接 → agentation
• 以 Codex 为先的运行时编排 → omx
• 采用 Gemini / Antigravity 便携式工具框架 → ohmg
• 跨 Codex 或 Antigravity 实现 Claude 工作流兼容 → 使用跨运行时兼容数据包，然后将运行时特定命令转交给 omx 或 ohmg

第 5 步：确保答案如实反映变化

OMC 上游项目变化很快。优先考虑：

• 首先确保拓扑信息准确
• 当前各入口的区别
• 当前安装／设置命令
• 当前路由去向
• 深入了解操作细节时参考文档

避免：

• 假装所有命令都属于同一个入口
• 把 /team 和 omc team 视为可互换
• 承诺 /ultraqa、$ultraqa 和 OMA /review 是同一种实现，而不是映射后的工作流意图
• 声称存在通用的 omc autopilot CLI
• 当重复路径的症状表明应先恢复时，仍叠加安装
• 将浏览器审查、审批或非 Claude 运行时的所有权纳入 OMC

示例

示例 1：安装 Marketplace 插件

用户：“我想安装 OMC，并立即在 Claude Code 中使用团队模式。”

**回复：**使用 install-topology 数据包，并采用 marketplace-plugin 拓扑。提供插件安装路径，然后说明 setup omc 或 /oh-my-claudecode:omc-setup，并在预期使用原生团队时提及 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1。

示例 2：本地 checkout／plugin-dir

用户：“我在用本地 checkout 修改 OMC，但 Claude 插件缓存一直保留旧行为。该如何设置 plugin-dir？”

**回复：**使用 install-topology 数据包，并采用 local-plugin-dir 拓扑。指出 --plugin-dir、OMC_PLUGIN_ROOT 和 omc setup --plugin-dir-mode，然后引导操作者查看 install-topology 参考文档，而不是把这当作普通的 Marketplace 安装。

示例 3：Shell 端工作线程团队

用户：“我想在 shell 中安排两个 codex 审查 auth 流程。”

**回复：**使用 terminal-runtime 数据包。推荐 omc team 2:codex "review auth flow"，将答案限定在 CLI 运行时，并仅在有帮助时提及状态／关闭命令。

示例 4：长循环编排边界

用户：“我想从规划、执行、验证到恢复都通过一个长期循环来运行。”

**回复：**使用 boundary-and-route-out 数据包。将长期循环协调工作路由到 jeo，并说明 OMC 只是 jeo 可能组合使用的、优先面向 Claude 的运行时。

示例 5：多种重复安装症状

用户：“更新后 slash 命令显示重复，而且每个 worktree 的状态也都不对劲。”

**回复：**使用 recovery-and-update 数据包，并采用 mixed-or-unknown 拓扑。告知对方检查是否存在重叠的插件／CLI／plugin-dir 安装，然后重新运行准确的设置／更新路径，并检查 worktree／状态行为，再选择其他模式。

最佳实践

1. 涉及安装或恢复时，先说明 拓扑，再说明数据包。
2. 推荐一种模式，再提供一个相近的替代方案，不要一次性倾倒大量命令。
3. 将 /team 和 omc team 视为相关但不同的运行时。
4. 明确说明 npm／软件包名称不匹配：oh-my-claude-sisyphus 提供 omc CLI。
5. 不要自行揣测 --plugin-dir 或重复安装症状；应引导至拓扑参考文档。
6. 将长期循环编排、审批策略、浏览器审查及其他运行时所有权问题路由到外部。
7. 对于 Codex 或 Antigravity 的兼容工作，先映射工作流意图，再移交给 omx 或 ohmg；不要将它们的运行时状态写入 .omc/。
8. 易变的操作细节应参考文档；入口内容应专注于准确路由。

参考资料

• references/install-topology-and-recovery.md
• references/intake-packets-and-route-outs.md
• references/modes-reference.md
• references/cross-runtime-workflow-map.md
• references/hooks-reference.md
• references/cli-reference.md
• references/agents-catalog.md