commandcode-delegate

Command Code 委任

あなたはオーケストレーターです。このスキルを使うと、範囲を限定したコーディングタスクを別の 実装担当者である Command Code CLI（cmd）に委任し、その成果を確認して自分で反映できます。 依頼内容を作成し、判断の責任を担うのはあなたです。Command Code は作業ツリーでコードを記述し、あなたが 検証してコミットします。

ここに記載する内容は、特定のオーケストレーションエージェントに限定されません。この一連の流れにはシェル コマンドを実行してファイルを読み取る機能だけが必要なので、Claude Code、モデルを選択した OpenCode、または同等のエージェントで同じように動作します。（Claude Code 向けに設計され、Claude Code で実行されています。他のオーケストレーターは、設計上の対象ではありますが、まだ検証されていないものとして扱ってください。）

使用しない場合

• タスクがそのまま実行できるほど小さい場合。委任にかかる手間に見合いません。
• cmd CLI がインストールされていない、または認証されていない場合（cmd login を実行してください）。
• 自分でコードを書きたい場合、またはレビューだけが必要な場合（Command Code には専用の /review があります）。
• ネイティブ Windows 環境で cmdc --version が動作しない場合。安定した Windows 利用には WSL を推奨しています。

最初に依頼する前に読む：自律性のモデル

Command Code のヘッドレスモードには、中間の状態がなく、次の 2 つの状態しかありません。

• デフォルト（--yolo を付けずに -p を指定）： 読み取り、grep、glob は動作します。すべての書き込み、編集、シェル呼び出しは CLI の権限レイヤーで拒否され、ヘッドレスモードでは実行中に許可を与えるプロンプトもありません。これはリレーの --read-only に相当します。
• --yolo（別名 --dangerously-skip-permissions）： プロセスがアクセスできる範囲で、すべてのツールが許可されます。ファイルシステムのサンドボックスも、パスの制限もありません。実装の実行にはこの設定が必要なため、リレーではデフォルトでこのオプションを渡します。

--permission-mode auto-accept と --tools-all を指定しても、ヘッドレスモードの書き込み制限は解除されません。CLI を直接試したところ、どちらを指定しても書き込み、編集、シェルは拒否されました。そのため、Command Code による実装の実行は全面的な信頼を与える実行です。サンドボックスではなく、明確に絞り込んだ依頼内容とクリーンな作業ツリーで範囲を限定してください。依頼内容はあくまで指針であり、git worktree はチェックアウトを隔離しますが、プロセスを封じ込めるものではありません。対象ツリー外への書き込みを許容できない場合は、codex-delegate のような OS 強制のサンドボックスを使うか、コンテナ内で実行してください。

前提条件（一度確認）

1. cmd --version が成功し、cmd status で認証済みと表示されること。そうでない場合は、Command Code をインストールして cmd login を実行してください。
2. CLI が PATH 上にあることを確認します。 macOS/Linux では、command -v cmd で有効な cmd を確認できます。ネイティブ Windows では cmdc --version を使ってください。cmd はシステムシェルです。リレーはそこで cmdc を使い、npm の .cmd シムを cmd.exe 経由で起動します。COMMANDCODE_BIN は引き続き絶対パスでの上書き設定であり、システムのコマンドインタープリターを指してはなりません。リレーは実行したバージョンを result.json に記録するため、誤ったバイナリを使用した場合は後から確認できます。
3. 対象の git リポジトリ内にいる（または --cd で対象のリポジトリを指定する）こと。また、依頼する前にツリーがクリーンであること。全面的な信頼を与える実行は、クリーンなベースラインと比較したほうがはるかに確認しやすくなります。

一連の流れ

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

1. 依頼内容を作成する

Command Code に見えるのは、あなたが送信したテキストだけです。リポジトリ内の AGENTS.md（自動的に読み取ります）を除き、リポジトリの記憶、チャット履歴、共有コンテキストはありません。タスクに必要な内容はすべて依頼に含めてください。目的、現状、変更内容、変更しない箇所、プロジェクトで実際に使われているゲート用コマンド（リポジトリの AGENTS.md／CLAUDE.md／Makefile で確認し、決めつけないでください）、そして報告の要件を記載します。コミットは行わないこと（コミットするのはあなたです）も伝えてください。依頼 1 件につきタスクは 1 つにしてください。詳しいガイダンスとテンプレートについては、references/writing-the-brief.md を参照してください。

2. ディスパッチ

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

バンドルされたヘルパーを使って、依頼内容を Command Code に送信します。ヘルパーは cmd -p をラップし、実行内容を取得して、構造化された result.json を書き込みます。つまり、あなたの作業は「コマンドを実行して、ファイルを読む」だけです。（以下の <skill-dir> は、このスキルがインストールされているディレクトリ、つまりこの SKILL.md を含むフォルダーです。スキルを読み込むと、Claude Code では「このスキルのベースディレクトリ」として表示されます。ほかのオーケストレーターでは同じディレクトリを使用してください。場所が分からない場合は、find ~ -name relay.mjs -path '*commandcode-delegate*' を実行し、その直上のディレクトリを指定してください。）

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# read-only (review/diagnosis, no edits):   add --read-only
# continue the exact session:               add --session <sessionId>  (from result.json; send only the delta brief)
# fallback when no session id is available: add --continue-last
# hard time limit (watchdog):               add --timeout 2h  (default: off; implementation runs routinely need 1-2h)
# see all options:                          node .../relay.mjs --help

ヘルパーはデフォルトで、書き込み可能な（--yolo）実行を行います。これは意図的に対象のリポジトリを編集します。一時ディレクトリにより、リポジトリの外に置かれるのはリレーの成果物だけです。リレーがコミットすることはありません。手順 5 を参照してください。仕組み、フラグ、result.json の形式については、references/dispatch-and-poll.md を参照してください。

3. 完了を待つ

codex-background を使う Codex では、元の MCP リクエストが保留状態に保たれます。モデル主導のスリープ、ステータスのポーリング、ログのポーリングは行いません。リクエストが中断された後に再アタッチする場合に限り、delegate_wait を使用してください。

ヘルパーは Command Code が完了するまでブロックするため、オーケストレーターが提供する方法で実行し、戻ってきたら再開してください。

• Claude Code： Bash 呼び出しを run_in_background: true で実行してください。完了すると通知されます。
• 通常のシェル／ほかのエージェント： 短いタスクではフォアグラウンドで実行するか、バックグラウンドで実行して結果ファイルをポーリングしてください。bash/zsh では … & を使い、ほかのシェルでは同等の方法を使います。result.json に status が記録されると実行完了です。（実行前の使用方法エラー（引数の誤りや依頼内容が空の場合）は、終了コード 2 と stderr メッセージを出力して終了し、結果ファイルを書き込みません。そのため、終了コードも確認してください。cmd バイナリが見つからない場合は終了コード 127 で終了しますが、commandcode_unavailable ステータスの result.json は書き込まれます。）

進捗トラッカーを実際の状況より優先してはいけません。result.json が書き込まれ、プロセスが終了した時点で実行完了です。ステータス行ではなく、作業ツリーを確認してください。実装担当者の完全な報告は result.json の finalMessage フィールドにあります（報告マーカーで囲まれた部分として、stdout にも全文が出力されます）。

4. レビュー — 自己申告を信用しない

result.json には、Command Code による独自の要約とゲートの通過報告が含まれています。そのまま受け入れず、必ず再確認してください。

• プロジェクトのゲートを自分で再実行してください（手順 1 のテスト／lint／ビルドコマンド）。「ゲートを通過した」という報告をうのみにしてはいけません。
• **依頼内容と照らし合わせて差分を確認してください。**依頼どおりに実施され、それ以上（スコープの逸脱）でも、それ以下でもないことを確認します。結果の touchedFiles を確認の出発点とし、実行は完全な信頼で行われたため、依頼で指定されたパスの内側だけでなく、パスの外側に編集がないかも確認してください。
• インストール済みであれば、差分に関連するガードスキル（guard-skills の clean-code-guard、test-guard など）を実行してください。このスキルが作業を行い、それらのスキルが作業を評価します。
• スキーマ／マイグレーションの変更はラウンドトリップで検証し、削除を行った場合は参照が残っていないか grep で確認してください。

完全なチェックリストについては、references/review-and-land.md を参照してください。

5. 変更を確定する

リレーはコミットしませんが、--yolo の下で Command Code が .git に書き込むのを阻止することはできません。ブリーフでは実装者によるコミットを禁じており、レビュー担当者は変更を確定する前に、HEAD と記録済みのディスパッチ前のベースラインを比較します。コミットするのはオーケストレーターです。 ゲートを通過し、差分に問題がないことを確認した後に限り、次の操作を行います。

• 検証済みの作業を、明確なメッセージを添えて自分でコミットします。
• 変更が必要な場合は、前回の result.json にある --session <sessionId> を使って差分ブリーフを送り、再度レビューします（セッション ID がない場合に限り、--continue-last を使用します）。

読み取り専用のセカンドオピニオン

リレーは、敵対的な視点からセカンドオピニオンを得る手段としても使えます。合意した点と、双方の立場を示した争点を列挙したブリーフを添えて --read-only でディスパッチし、それぞれの争点について Command Code に立場を擁護するか譲歩するよう求めます。成果物は最終メッセージで提出し、ファイルには一切触れません。ここでの読み取り専用の保証は OS のサンドボックスではなく、CLI 独自の権限レイヤーによるものです。そのためリレーは事後にも確認します。readOnlyViolation: false は Git から確認できる検出器が変更を検出しなかったことを意味します（無視対象のパスやリポジトリ外のパスは対象外です）。true は変更を検出したことを意味し、null は git で判定できなかったことを意味します。

承認モデル

委任するかどうかは、人間が選択します。人間が「このキューを実行して」「続行して」と指示した時点で、検証済みでゲートを通過した作業をコミットすることが合意済みの契約となります。それが委任の目的です。この権限には次の2つの制限があります。隠さず提示する（Command Code の設計上の判断、擁護可能だが依頼されていない方向転換、ブロック要因ではない細かな指摘を、黙って受け入れるのではなく報告する）こと、そしてスコープの変更時には停止する（正しく完了するためにブリーフの範囲を超える必要がある場合は、自分で権限を拡大せず、確認を求める）ことです。詳しくは references/review-and-land.md を参照してください。

参考資料

• references/writing-the-brief.md — Command Code が指示を受けずに実行できるブリーフの書き方：構成、XML ブロック、レポートの契約、実際のゲートコマンドの埋め込み方。
• references/dispatch-and-poll.md — relay.mjs のフラグ、result.json の契約、オーケストレーターごとのバックグラウンド実行、実行に問題が生じた場合の復旧方法。
• references/review-and-land.md — レビューチェックリスト、コミットの境界、同一セッションでの正確な再作業サイクル。
• references/multi-task-queues.md — 順次キューの実行方法：制約の引き継ぎ、進捗の追跡、実行終了時の一貫性チェック。