omp-delegate

Oh My Pi Delegate

あなたはオーケストレーターです。範囲を限定したコーディングタスクを別の実装担当である Oh My Pi（omp）に委任し、実装内容をレビューして、自分で取り込みます。依頼内容を作成し、判断の責任を負うのはあなたです。実装担当は独自のセッションで変更を加え、その後、あなたが検証してコミットします。

この一連の流れに必要なのはシェルコマンドとファイルアクセスだけなので、同等のオーケストレーターであればどれでも実行できます。

バイナリは pi ではなく omp

Oh My Pi は Pi のフォークです。このスキルが操作するのは omp（@oh-my-pi/pi-coding-agent）です。元の Pi CLI は別のバイナリ（pi）を使用し、別のスキル（pi-delegate）に対応します。omp が見つからず、pi がインストールされている場合は、Oh My Pi ではなく Pi を使用しています。

使用しないケース

• タスクがインラインで実行できるほど小さい場合。委任のオーバーヘッドに見合いません。
• omp CLI がインストールされていないか、認証されていない場合。
• ユーザーが元の Pi CLI（pi）を指定している場合は、pi-delegate を使用してください。
• サンドボックス化された実装担当が必要な場合。Oh My Pi にはサンドボックスがありません。--read-only でツールの利用範囲を制限できます。書き込み可能な実行はプロンプトなしで実行されます（--yolo）。

前提条件（一度だけ確認）

1. bun install -g @oh-my-pi/pi-coding-agent（または https://omp.sh のインストール手順）で omp をインストールします。
2. 認証します。サブスクリプションプロバイダーの場合は omp 内で /login を実行し、API キープロバイダーの場合は API キーの環境変数を設定します。認証情報は ~/.omp/ に保存されます。
3. omp --version が成功することを確認します。
4. 対象の Git リポジトリ内で作業するか、--cd でそのリポジトリを指定します。

モデルを選ぶ（任意）

--model（および --provider）を省略すると、このプロジェクト／プロファイルに設定されている omp のデフォルトが使われます。カタログに含まれるのは、このスキルで固定された一覧ではなく、このインストール環境で認証済みのプロバイダーです。

別のモデルを選ぶには、次の手順に従います。

1. このインストール環境で実際に実行可能なものを一覧表示します。 omp --list-models は渡さないでください。このフラグは廃止されており、omp は未知のフラグとして扱って終了コード 2 を返します。models サブコマンドを使用してください。
   • omp models — 利用可能なすべてのモデルをプロバイダーごとに表示します
   • omp models --json — 同じカタログを機械可読形式で表示します
   • omp models find <substring> — プロバイダー、ID、名前で絞り込みます（例：omp models find sonnet）
   • omp models <provider> — 1 つのプロバイダーのモデルを表示します
2. その ID をリレーに渡します。 --model <pattern> は omp 独自の --model で、カタログとあいまい一致します（プロバイダー／ID、ID のみ、または一意の部分文字列）。パターンが曖昧な場合は、--provider <name> でプロバイダーを固定します。
3. リレーが転送するのは、英字、数字、および . _ : / - のみです。* を使ったグロブパターンは拒否されます。

--thinking <level> はモデル ID とは別の推論レベル設定です。指定できる値は off、auto、minimal、low、medium、high、xhigh、max です。リレーはこれ以外の値（inherit を含む）をディスパッチ前に拒否します。そうしないと、omp は無効な値に警告を出して無視します。

フリートレーン（--lane）では、provider、model、effort を設定できます。レーンの effort は --thinking になります。明示的に指定した --thinking／--model／--provider フラグは、レーンの設定より優先されます。

リレーは --api-key、--smol、--slow、--plan を転送しません。これらは omp 独自の CLI に渡すフラグです。

一連の流れ

タスクごとに、次の 5 つのステップを実行します。ステップ 1、4、5 では判断が必要ですが、2 と 3 は機械的な作業です。

1. 依頼内容を作成する

Oh My Pi が確認できるのは、送信したテキストとワークスペース内で調べられる内容だけです。チャット履歴や共有コンテキストはありません。目標、現状、変更する内容、変更せずに残す内容、プロジェクトの実際のゲート、報告形式を含めてください。omp にはコミットしないよう伝えてください。依頼 1 件につきタスクは 1 つにします。omp はワークスペースとその親ディレクトリにある AGENTS.md／CLAUDE.md コンテキストファイルを自動的に読み込むため、リポジトリの指示を依頼文に含めなくても伝えられます。references/writing-the-brief.md を参照してください。

2. ディスパッチ

Codex でバックグラウンド作業をオーケストレーションする場合は、まず別途提供される codex-background サポートユーティリティをインストールして設定してください。MCP ツールまたはレジストリが 見つからない場合は停止し、セットアップが必要であることを報告してください。モデル主導のポーリングに 暗黙にフォールバックしてはいけません。その後、以下のシェルの例に代えて、登録済みの delegate_run MCP ツールを一度呼び出してください。 構造化された共通引数、変更していないプロバイダーフラグ、runId による再接続については、 そのスキルに従ってください。完了するまでリクエストを保留し、その後このスキルのレビューと コミットの手順を続けてください。ほかのオーケストレーターでは、以下のシェルワークフローを使用します。

同梱のリレーを使用してください。リレーは brief を標準入力で omp --mode json に渡し、JSON イベント ストリームを取得して result.json に書き込みます。（<skill-dir> は、この SKILL.md を含むインストール済みのフォルダーです。）

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# list models first:                       omp models   (or: omp models --json)
# choose a model:                          add --model <id from omp models>
# choose a provider:                       add --provider <name>
# set thinking level:                      add --thinking high
# read-only run (review/diagnosis):        add --read-only
# trust project .omp resources:            add --approve
# resume the most recent session:          add --resume-last  (delta brief only)
# resume a specific session:               add --session <id> (delta brief only)
# hard time limit (watchdog):              add --timeout 2h  (the 30m default suits short runs; implementation briefs routinely need 1-2h)
# see all options:                         node .../relay.mjs --help

子プロセスの cwd がワークスペースを固定します。リレーは既定でシステムの一時ディレクトリに 成果物を書き込み、コミットは行いません。references/dispatch-and-poll.md を参照してください。

3. 完了を待つ

codex-background を使用する Codex では、元の MCP リクエストを保留したままにします。モデル主導の スリープ、ステータスのポーリング、ログのポーリングは行いません。中断されたリクエストへの再接続には delegate_wait のみを使用してください。

リレーは omp の完了までブロックします。オーケストレーターのバックグラウンドコマンド機能を使って実行するか、 シェルでバックグラウンド実行して result.json をポーリングしてください。実行前の使用方法エラーでは 終了コード 2 が返され、結果は書き込まれません。omp が見つからない場合は終了コード 127 が返され、 status: "omp_unavailable" が書き込まれます。

進捗表示よりも、プロセスの状態と作業ツリーを信頼してください。完了とは、プロセスが終了し、 result.json が存在する状態です。omp の完全なレポートは result.json の finalMessage フィールドに 記録されています（レポートマーカーの間に、標準出力にも全体が出力されます）。

4. レビュー — 自己申告を鵜呑みにしない

omp の最終メッセージとゲートの通過に関する主張は、あくまで主張として扱ってください。

• プロジェクトのゲートを自分で再実行してください。
• brief に照らして差分を読み、touchedFiles から確認を始めてください。
• インストール済みであれば、関連するガードスキルを実行してください。
• マイグレーションを往復実行し、削除や名前変更の後に参照が残っていないか grep で確認してください。

references/review-and-land.md を参照してください。

5. コミットする

実装担当者は作業ツリーを編集し、オーケストレーターがコミットします。 ゲートを通過し、 差分に問題がないことを確認してからコミットしてください。手直しが必要な場合は、 --resume-last または --session <id> を使って差分 brief を送り、再度レビューしてください。

自律性と権限

Oh My Pi にはサンドボックスがありません。プリントモードには承認 UI がないため、書き込み可能な リレー実行では常に --yolo（tools.approvalMode: yolo）を渡します。そうしないと、ユーザーの always-ask または write の設定によって、ウォッチドッグがタイムアウトするまで処理が停止します。 そのほかの制御方法は次のとおりです。

1. --read-only を指定すると、omp が呼び出せるツールは --tools read,grep,glob に制限されます。 --yolo は渡されません。プロジェクトのリソースが信頼されている場合、インストール済みの拡張コードは 引き続きユーザーのホスト権限で実行されます。
2. リレーは既定で --no-extensions --no-skills --no-rules を渡すため、プロジェクトの .omp 拡張機能、スキル、ルールは検出されません。ユーザーがリポジトリを信頼している場合は、 --approve で明示的に許可してください。
3. 変更内容の記録は touchedFiles と差分です。実行のたびに確認してください。

承認モデル

委任を行うかどうかは、人間が選択します。いったん委任を選択した後（「このキューを実行して」 「続行して」など）、検証済みでゲートを通過した作業をコミットすることが合意された契約です。 ただし、次の 2 つの制限は残ります。隠さず報告すること（omp の設計上の判断、正当化できるものの 依頼されていない対応、ブロック要因にならない細かな問題を報告すること）、およびスコープ変更が必要なら 停止すること（brief の範囲を超えなければ正しく完了できない場合は、権限を拡大せず、確認を求めてください）。 references/review-and-land.md を参照してください。

参考資料

• references/writing-the-brief.md - 構成、レポートの契約、実際のゲート、stdin による受け渡し、モデル一覧、差分ブリーフ。
• references/dispatch-and-poll.md - フラグ、成果物、result.json、ポーリング、障害からの復旧。
• references/review-and-land.md - レビューチェックリスト、コミットの境界、omp セッションを通じた手直し。
• references/multi-task-queues.md - 順次キュー、制約の引き継ぎ、進捗の追跡、最終的な整合性チェック。