omc

omc — oh-my-claudecode 向けの Claude ファーストなトポロジー対応ルーター

このスキルを使う場面

• ユーザーが OMC／oh-my-claudecode を通じて、Claude Code ネイティブのオーケストレーションを求めている
• ユーザーがマーケットプレイスプラグイン、omc シェル 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 の混乱、worktree／状態の競合、セットアップのずれ、または HUD／レート制限／再開に関する問題に直面している
• ユーザーが本当に求めているのが、jeo、ralphmode、omx、ohmg、ブラウザレビュー用スキルではなく、Claude ファーストのランタイムオーナーである

手順

ステップ 1：コマンドを提示する前に、インストールのトポロジーを特定する

コマンドを提案する前に、オペレーターが実際にどの OMC トポロジーを使用しているかを特定します。

1. marketplace-plugin — マーケットプレイスからインストールした Claude Code プラグイン／スラッシュスキルの環境
2. shell-cli — シェル側のセットアップ、tmux ワーカー、またはプロバイダーへの問い合わせに使う、npm でインストールした omc コマンド
3. local-plugin-dir — ローカルチェックアウト／--plugin-dir／OMC_PLUGIN_ROOT ワークフロー
4. mixed-or-unknown — プラグインと CLI とローカルチェックアウトの併用、コマンドの重複、または不明確なセットアップ状態

トポロジーが mixed-or-unknown の場合は、コマンドを追加で提案する前に、復旧とトポロジーの明確化を優先します。

ステップ 2：リクエストに適したパケットを選ぶ

トポロジーが十分に明確になったら、実際の作業を次のいずれかに分類します。

1. install-topology — インストール、初回セットアップ、ローカルチェックアウト／plugin-dir の選択
2. in-session-runtime — Claude Code 内で適切なスラッシュスキルを選ぶ
3. terminal-runtime — 適切な omc ... シェルコマンドを選ぶ
4. recovery-and-update — インストールの重複、セットアップのずれ、worktree／状態の問題、HUD／フック、または再開に関する問題を修正する
5. cross-runtime-parity — ランタイムが同一であるかのように扱わず、Claude のスラッシュワークフローを OMX または OMA に対応付ける
6. boundary-and-route-out — リクエストが本来 jeo、ralphmode、plannotator、ブラウザレビュー用スキル、または別のランタイムに属する

まず頭の中でトポロジーとパケットを決め、その組み合わせに合ったコマンドだけを提示します。

ステップ 3：使用している環境をオペレーターに伝える

OMC には実際に 2 つのランタイム環境があります。ひとまとめにしないでください。

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 環境

ユーザーがシェル側のセットアップ、更新、プロバイダーへの問い合わせ、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 ワーカー
• シェル側のランタイム管理

重要な事実：

• /team と omc team は異なるランタイムです
• /autopilot、/ralph、/ultrawork はセッション内スキルであり、通常の omc CLI サブコマンドではありません
• npm パッケージ名は oh-my-claude-sisyphus であり、oh-my-claudecode ではありません

ステップ 4：適切なトポロジーとパケットの組み合わせを使う

パケット：install-topology

インストール、セットアップ、またはトポロジーのクリーンアップが必要な場合に使用します。

marketplace-plugin

Claude Code 内で：

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

次に、Claude Code 内でセットアップのエントリーポイントを 1 つ実行します：

setup omc

または：

/oh-my-claudecode:omc-setup

shell-cli

omc のシェルコマンドも使いたい場合：

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

local-plugin-dir

マーケットプレイス経由の方法だけで十分だと決めつけないでください。クリーンアップの方法を独自に判断する前に、プラグインディレクトリ／ローカルチェックアウトの方法と専用リファレンスを案内してください：

• 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"
  }
}

パケット：in-session-runtime

タスクに最適な Claude Code のスラッシュスキルをユーザーが求めている場合に使用します。

ニーズ	使用するもの	理由
セッション内で共有するマルチエージェント作業	/team ...	正式な Claude ネイティブのチームワークフロー
曖昧な依頼からエンドツーエンドで構築	/autopilot ... または autopilot: ...	1 つのリードエージェントが、アイデアから実装まで担当
検証済みの完了まで作業を続ける必要がある場合	/ralph ... または ralph: ...	継続的な実行 → 検証 → 修正のループ
一気に並列で作業	/ultrawork ... または ulw ...	チーム全体のオーバーヘッドなしで高い並列性を実現
QA／レビューを並列で一気に実施	インストール済みの場合は /ultraqa ...	QA を複数に振り分けます。対象のランタイムが Claude 以外の場合は、OMX の $ultraqa または OMA の /review を案内します
まず要件を明確化	/deep-interview ...	計画や実行の前に要件を明確化
複数モデルの統合	上流またはランタイムが対応している場合は ccg: ...	助言を目的とした統合経路

適切な推奨を 1 つ選び、近い代替案は最大 1 つまでにしてください。

パケット：terminal-runtime

セッション内のプラグインではなく、シェル CLIをユーザーが求めている場合に使用します。

ニーズ	使用するもの
シェル側の初回インストール／修復	omc setup
更新後の再読み込み	omc update
プロバイダーへの相談	omc ask <provider> "..."
tmux ベースのワーカーチーム	omc team <N>:<provider> "<task>"
チームランタイムの状態	omc team status <session>
チームランタイムのシャットダウン	omc team shutdown <session>

ユーザーが「チームモード」と言っていて、すでに Claude Code 内にいる場合は、/team を優先してください。 ユーザーが「チームモード」と言っていて、シェル／tmux ワーカーを明確に求めている場合は、omc team を優先してください。

パケット：cross-runtime-parity

ユーザーが 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 形式のカスタムサブエージェント生成機能があると主張しないでください。必要に応じて OMA CLI にフォールバックします。
• 対象が Codex ネイティブの場合、オペレーター向けの詳細は omx に案内します。
• Gemini／Antigravity のポータブルハーネス作業が対象の場合、オペレーター向けの詳細は ohmg に案内します。

パケット：recovery-and-update

実際の作業が OMC の修復である場合に使用します。

主な復旧パターン：

• インストールやコマンドの重複 → マーケットプレイスプラグイン、npm CLI、ローカルチェックアウト／plugin-dir の各インストールが重複していないか確認します
• アップグレード後のセットアップのずれ → 現在の構成に合った正しいセットアップ／更新手順を再実行します（setup omc、/oh-my-claudecode:omc-setup、omc update、omc setup）
• ローカルチェックアウトがマーケットプレイスインストールと同じように動作しない → むやみに再インストールせず、--plugin-dir、OMC_PLUGIN_ROOT、plugin-dir モードを確認します
• チームモードが動作しない → CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を確認します
• ワークツリー／状態の異常 → .omc/state/、ワークツリーの名前空間の動作、チーム名／セッション名を確認します
• HUD／レート制限／一時的な環境に関する問題 → モード選択の問題ではなく、環境／ランタイムの復旧として扱います

修正に詳細な対応が必要な場合は、以下に案内します：

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

パケット：boundary-and-route-out

別のスキルのほうが適切に対応できる作業に、OMC を無理に使わないでください。

以下の場合は別のスキルに案内します：

• 長期間維持する計画／実行台帳／複数スキルにまたがる再開可能なループ → jeo
• OMC のランタイム詳細を超える、仕様優先の永続化手法 → ralph
• 承認方針、信頼済みフォルダー／バイパスポリシー、権限の適用範囲 → ralphmode
• 計画のレビュー／承認ゲート → plannotator
• 新しいセッションでのブラウザー検証 → browser-harness
• 認証済みの実行中ブラウザーの再利用 → playwriter
• 正確にレンダリングされた UI の批評／注釈の引き継ぎ → agentation
• Codex を優先するランタイムオーケストレーション → omx
• Gemini／Antigravity のポータブルハーネスの導入 → ohmg
• Codex または Antigravity における Claude ワークフローの同等性 → cross-runtime-parity パケットを使用してから、ランタイム固有のコマンドについて omx または ohmg に案内します

ステップ 5：変更の速さを踏まえ、回答の正確性を保つ

OMC は上流プロジェクトの変更が非常に速いプロジェクトです。以下を優先してください。

• まずトポロジーの正確性
• 現在のインターフェースの違い
• 現在のインストール／セットアップコマンド
• 現在のルート先
• オペレーター向けの詳しい説明にはリファレンスドキュメントを使用

以下は避けてください。

• すべてのコマンドがひとつのインターフェースにあるかのように扱う
• /team と omc team を同じものとして扱う
• /ultraqa、$ultraqa、OMA の /review が、マッピングされたワークフローの意図ではなく、同じ実装だと約束する
• 一般的な omc autopilot CLI があると主張する
• 重複パスの症状から先に復旧が必要と考えられる場合に、インストールを重ねる
• ブラウザレビュー、承認、または Claude 以外のランタイムの管理を OMC に取り込む

例

例 1：マーケットプレイスプラグインのインストール

ユーザー：「OMC をインストールして、Claude Code 内ですぐにチームモードも使いたい」

回答： install-topology パケットと marketplace-plugin トポロジーを使用します。プラグインのインストール手順を案内し、次に setup omc または /oh-my-claudecode:omc-setup を示します。ネイティブチームを使う場合は CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 が必要であることも伝えます。

例 2：ローカルチェックアウト／plugin-dir

ユーザー：「ローカル checkout で OMC を修正しているけど、Claude の plugin cache のせいで古い動作が残り続ける。plugin-dir を使うにはどうすればいい？」

回答： install-topology パケットと local-plugin-dir トポロジーを使用します。--plugin-dir、OMC_PLUGIN_ROOT、omc setup --plugin-dir-mode を案内し、通常のマーケットプレイスインストールとして扱わず、オペレーターを install-topology リファレンスに誘導します。

例 3：シェル側のワーカーチーム

ユーザー：「shell で codex を二人使って、auth フローのレビューを回したい」

回答： terminal-runtime パケットを使用します。omc team 2:codex "review auth flow" を推奨し、回答は CLI ランタイムに絞ります。役立つ場合に限り、ステータス／シャットダウンコマンドについても触れます。

例 4：長期ループのオーケストレーション境界

ユーザー：「企画から実行、検証、再開までをひとつの長期ループとして動かしたい」

回答： boundary-and-route-out パケットを使用します。長期ループの調整レイヤーとして jeo に誘導し、OMC は jeo が組み合わせて使う可能性のある、Claude を第一に想定したランタイムとしてのみ紹介します。

例 5：インストール重複の複合的な症状

ユーザー：「アップデート後、slash command が重複して表示され、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