Route Claude Code–first orchestration to the truthful OMC install topology and runtime before giving commands. Use when the user wants oh-my-claudecode / OMC in Claude Code, needs to choose between marketplace plugin, shell-side `omc` CLI, or local-checkout `--plugin-dir` usage, or needs accurate guidance on `/team`, `/autopilot`, `/ralph`, `/ultrawork`, `/ultraqa`, `omc setup`, `omc team`, `omc ask`, updates, HUD/hooks, duplicate installs, worktree/state drift, or mapping Claude workflows to Codex/OMX and Gemini/Antigravity/OMA. Triggers on: omc, oh-my-claudecode, Claude Code team mode, autopilot, /team, ralph, ultrawork, ultraqa, ccg, omc team, omc ask, omc setup, plugin-dir, OMC HUD, OMC hooks.
Route Claude Code–first orchestration to the truthful OMC install topology and runtime before giving commands. Use when the user wants oh-my-claudecode / OMC in Claude Code, needs to choose between marketplace plugin, shell-side `omc` CLI, or local-checkout `--plugin-dir` usage, or needs accurate guidance on `/team`, `/autopilot`, `/ralph`, `/ultrawork`, `/ultraqa`, `omc setup`, `omc team`, `omc ask`, updates, HUD/hooks, duplicate installs, worktree/state drift, or mapping Claude workflows to Codex/OMX and Gemini/Antigravity/OMA. Triggers on: omc, oh-my-claudecode, Claude Code team mode, autopilot, /team, ralph, ultrawork, ultraqa, ccg, omc team, omc ask, omc setup, plugin-dir, OMC HUD, OMC hooks.
cross-runtime-parity — map Claude slash workflows to OMX or OMA without pretending the runtimes are identical
boundary-and-route-out — the request really belongs to jeo, ralphmode, plannotator, browser-review skills, or another runtime
Lead with the topology and packet mentally, then give only the commands that fit that combination.
Step 3: Tell the operator which surface they are on
OMC has two real runtime surfaces. Do not flatten them.
A. Claude Code plugin / in-session surface
Use this when the user is already inside Claude Code and wants slash skills, hooks, HUD, or native team behavior.
Examples:
/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"
This surface owns:
slash skills
hooks and HUD behavior
native team orchestration inside Claude Code
in-session keywords like autopilot: or ralph:
B. Terminal CLI surface
Use this when the user wants shell-side setup, updates, provider consultation, tmux workers, or runtime management.
Examples:
omc setup
omc update
omc ask codex "review this patch"
omc team 2:codex "review auth flow"
omc team status review-auth-flow
This surface owns:
omc setup / omc update
omc ask
omc team tmux workers
shell-side runtime management
Important truth:
/team and omc team are different runtimes
/autopilot, /ralph, and /ultrawork are in-session skills, not normal omc CLI subcommands
the npm package name is oh-my-claude-sisyphus, not oh-my-claudecode
Step 4: Use the right topology + packet pair
Packet: install-topology
Use when the user needs installation, setup, or topology cleanup.
Do not pretend the marketplace flow is enough. Point them to the plugin-dir / local-checkout path and the dedicated reference before improvising cleanup:
Treat duplicate commands, duplicate slash skills, or unclear state as a recovery problem first. Do not stack more installs on top of an ambiguous topology.
Enable native teams in ~/.claude/settings.json when Claude-native teams are expected:
Use when the user wants the best Claude Code slash skill for the job.
Need
Use
Why
Shared in-session multi-agent work
/team ...
Canonical Claude-native team workflow
End-to-end build from a fuzzy request
/autopilot ... or autopilot: ...
Single lead agent, idea → implementation
Must keep going until verified done
/ralph ... or ralph: ...
Persistent execute → verify → fix loop
Burst parallel work
/ultrawork ... or ulw ...
High parallelism without full team overhead
Parallel QA / review burst
/ultraqa ... when installed
QA fan-out; route to OMX $ultraqa or OMA /review when the target runtime is not Claude
Requirements clarification first
/deep-interview ...
Clarify before planning or execution
Cross-model synthesis
ccg: ... when upstream/runtime supports it
Advisory synthesis path
Pick one truthful recommendation plus at most 1 nearby alternative.
Packet: terminal-runtime
Use when the user wants the shell CLI rather than the in-session plugin surface.
Need
Use
Initial shell-side install/repair
omc setup
Refresh after updates
omc update
Provider consultation
omc ask <provider> "..."
tmux-based worker teams
omc team <N>:<provider> "<task>"
Team runtime status
omc team status <session>
Team runtime shutdown
omc team shutdown <session>
If the user says “team mode” but is already inside Claude Code, prefer /team.
If the user says “team mode” and clearly wants shell/tmux workers, prefer omc team.
/orchestrate "task" or oma agent:parallel -i role:"task"
/autopilot "task" or autopilot: task
$autopilot "task"; use $deep-interview first for vague requests or $plan → $ralph for stricter verification
/plan "task" → /work; use /orchestrate or oma agent:parallel only when explicit parallel lanes are needed
/ultrawork "task" / ulw "task"
$ulw "task" or $ultrawork "task"
/ultrawork "task" or oma agent:parallel for independent lanes
/ultraqa "target"
$ultraqa "target"
/review "target" or /ultrawork "QA target"; use oma agent:parallel for explicit QA lanes
Rules:
State the runtime boundary first: OMC uses .omc/, OMX uses .omx/, OMA keeps .agents/ canonical.
Treat /autopilot as an intent contract, not a universal command name: Codex owns $autopilot; OMA usually composes /plan and /work.
Do not claim Antigravity has Claude-style custom subagent spawning; use OMA CLI fallback when needed.
When the target is Codex-native, route operator details to omx.
When the target is Gemini/Antigravity portable harness work, route operator details to ohmg.
Packet: recovery-and-update
Use when the real job is repairing OMC.
Top recovery patterns:
Duplicate install / duplicate commands → inspect whether marketplace plugin, npm CLI, and local-checkout/plugin-dir installs are overlapping
Setup drift after upgrade → rerun the truthful setup/update path for the current topology (setup omc, /oh-my-claudecode:omc-setup, omc update, omc setup)
Local checkout not behaving like marketplace install → verify --plugin-dir, OMC_PLUGIN_ROOT, and plugin-dir mode instead of reinstalling blindly
Team mode not working → verify CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Claude workflow parity across Codex or Antigravity → use the cross-runtime-parity packet, then route to omx or ohmg for runtime-specific commands
Step 5: Keep the answer truthful about volatility
OMC is a fast-moving upstream project. Prefer:
topology truth first
current surface distinctions
current install/setup commands
current route-outs
reference docs for deeper operator detail
Avoid:
pretending all commands live on one surface
treating /team and omc team as interchangeable
promising that /ultraqa, $ultraqa, and OMA /review are the same implementation rather than mapped workflow intents
claiming there is a general omc autopilot CLI
stacking installs when duplicate-path symptoms suggest recovery first
absorbing browser review, approvals, or non-Claude runtime ownership into OMC
Examples
Example 1: Marketplace plugin install
User: "OMC 설치하고 Claude Code 안에서 바로 팀 모드까지 쓰고 싶어"
Response: Use the install-topology packet with marketplace-plugin topology. Give the plugin install path, then setup omc or /oh-my-claudecode:omc-setup, and mention CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 when native teams are expected.
Example 2: Local checkout / plugin-dir
User: "로컬 checkout으로 OMC 수정 중인데 Claude plugin cache 때문에 계속 예전 동작이 남아. plugin-dir 쪽으로 어떻게 잡아야 해?"
Response: Use the install-topology packet with local-plugin-dir topology. Point to --plugin-dir, OMC_PLUGIN_ROOT, and omc setup --plugin-dir-mode, then send the operator to the install-topology reference instead of treating this like a normal marketplace install.
Example 3: Shell-side worker team
User: "shell에서 codex 두 명 붙여서 auth 플로우 리뷰 돌리고 싶어"
Response: Use the terminal-runtime packet. Recommend omc team 2:codex "review auth flow", keep the answer on the CLI runtime, and mention status/shutdown commands only if helpful.
Example 4: Long-loop orchestration boundary
User: "기획부터 실행, 검증, 재개까지 하나의 장기 루프로 굴리고 싶어"
Response: Use the boundary-and-route-out packet. Route to jeo as the long-loop coordination layer, and mention OMC only as the Claude-first runtime that jeo may compose with.
Example 5: Mixed duplicate install symptoms
User: "업데이트 후 slash command가 중복으로 보이고 worktree마다 상태도 이상해"
Response: Use the recovery-and-update packet with mixed-or-unknown topology. Tell them to inspect overlapping plugin/CLI/plugin-dir installs, then rerun the truthful setup/update path and inspect worktree/state behavior before choosing another mode.
Best practices
Name the topology before the packet when install or recovery is involved.
Prefer one recommended mode plus one nearby alternative, not a giant command dump.
Treat /team and omc team as related but different runtimes.
Keep the npm/package-name mismatch explicit: oh-my-claude-sisyphus provides the omc CLI.
Do not improvise over --plugin-dir or duplicate-install symptoms; route to the topology reference.
Route long-loop orchestration, approval posture, browser review, and other runtime ownership outward.
For Codex or Antigravity parity work, map the workflow intent and then hand off to omx or ohmg; do not write their runtime state into .omc/.
Use references for volatile operator detail; keep the front door focused on truthful routing.
