omc — Claude-first topology-aware router for oh-my-claudecode

When to use this skill

The user wants Claude Code–native orchestration through OMC / oh-my-claudecode
The user needs to choose between the marketplace plugin, the omc shell CLI, or a local checkout / --plugin-dir workflow
The user asks about /team, /autopilot, /ralph, /ultrawork, omc team, omc ask, omc setup, omc update, hooks, HUD, or OMC state behavior
The user is hitting duplicate installs, plugin-dir confusion, worktree/state collisions, setup drift, or HUD / rate-limit / resume trouble
The user really wants a Claude-first runtime owner, not jeo, ralphmode, omx, ohmg, or browser-review skills

Instructions

Step 1: Identify the install topology before the packet

Before suggesting commands, identify which OMC topology the operator is actually using:

marketplace-plugin — Claude Code plugin / slash-skill surface installed from the marketplace
shell-cli — npm-installed omc command for shell-side setup, tmux workers, or provider asks
local-plugin-dir — local checkout / --plugin-dir / OMC_PLUGIN_ROOT workflow
mixed-or-unknown — overlapping plugin + CLI + local checkout, duplicate commands, or unclear setup state

If the topology is mixed-or-unknown, prefer recovery and topology clarification before recommending more commands.

Step 2: Pick one request packet

After topology is clear enough, classify the actual job into one packet:

install-topology — install, first-run setup, or local-checkout / plugin-dir decisions
in-session-runtime — choose the right slash skill inside Claude Code
terminal-runtime — choose the right omc ... shell command
recovery-and-update — fix duplicate installs, setup drift, worktree/state trouble, HUD/hooks, or resume issues
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.

marketplace-plugin

Inside Claude Code:

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

Then run one setup entrypoint inside Claude Code:

setup omc

or:

/oh-my-claudecode:omc-setup

shell-cli

If they also want omc shell commands:

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

local-plugin-dir

Do not pretend the marketplace flow is enough. Point them to the plugin-dir / local-checkout path and the dedicated reference before improvising cleanup:

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

mixed-or-unknown

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:

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

Packet: in-session-runtime

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
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.

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
Worktree/state weirdness → inspect .omc/state/, worktree namespace behavior, and team/session names
HUD / rate-limit / ephemeral-environment trouble → treat it as environment/runtime recovery, not a mode-selection question

When the fix gets detailed, route to:

Packet: boundary-and-route-out

Do not force OMC when another skill owns the job better.

Route out when:

long-lived plan / execution ledger / resumable multi-skill loop → jeo
spec-first persistence method beyond OMC runtime detail → ralph
approval posture, trusted-folder / bypass policy, permission surface → ralphmode
plan review / approval gate → plannotator
fresh-session browser verification → agent-browser
running authenticated browser reuse → playwriter
exact rendered-UI critique / annotation handoff → agentation
Codex-first runtime orchestration → omx
Gemini / Antigravity portable harness adoption → ohmg

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
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.
Use references for volatile operator detail; keep the front door focused on truthful routing.

omc