mcode-delegate

MiniMax Code 委任

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

この仕組みは特定のオーケストレーターに依存しません。必要なのはシェルコマンドを実行してファイルを読み取る機能だけなので、Claude Code、選択したモデルを使う OpenCode、その他同等のエージェントで同じように動作します。（Claude Code 向けに設計され、Claude Code で実行されています。他のオーケストレーターについては、設計上は対応していますが、まだ実証されていないものとして扱ってください。）

使用しない場合

• タスクが小さく、その場で実行できる場合は使わないでください。委任のオーバーヘッドに見合いません。
• mcode がインストールされていない、またはサインインしていない場合（mcode login または mcode login --region global を実行してください）。
• 自分でコードを書きたい場合、またはローカルの変更をレビューするだけの場合（mcode exec review で直接実行できます）。
• 対象ツリーの外部への書き込みを、可能性が低いだけでなく不可能にする必要がある場合。MiniMax Code にサンドボックスはありません。codex-delegate などの OS によって強制されるサンドボックスを使うか、コンテナ内で実行してください。

初回の実行前にお読みください：自律性モデル

mcode exec では権限ポリシー（smart、full、off）を指定します。ヘッドレス実行にはサンドボックスも、読み取り専用や計画の設定もありません（ask を使うには TUI または ACP が必要です）。

• smart（リレーのデフォルト、TUI Auto）： ヘッドレス実行では、ファイルの書き込みと削除がすでに許可されています。実際の調査では、rm を要求したところ、プロンプトなしで実行されました。したがって、smart は安全策ではありません。依頼内容とクリーンな作業ツリーが、実際のスコープを定めます。
• full（TUI Full access）： 通常の確認を完全にスキップします。リレーがこれを渡すのは、明示的に --permission full を指定した場合のみです。
• off： リレーによって拒否されます。MiniMax Code は、これによって何が無効になるのかを文書化していません。

--read-only は参考的な指示です。リレーは編集を禁止するシステムプロンプトを追加し、smart を維持したうえで、Git から確認できる変更検知機能（readOnlyViolation）を実行します。変更は事前に防止されるのではなく、事後に検出されます。また、無視されるパスやリポジトリ外のパスは対象外です。

前提条件（初回のみ確認）

1. mcode --version が成功し、サインイン済みであること（TUI で mcode → /status）。そうでない場合は、MiniMax Code をインストールして mcode login を実行してください。
2. リレーが実行されるシェルで、mcode が PATH 上にあることを確認してください。 公式インストーラーは ~/.minimax-code/bin に配置しますが、PATH に追加されるのはシェルプロファイルを読み込んだ場合のみです。オーケストレーターの非ログインシェルからは見つからない場合があります。command -v mcode の結果が空の場合は、--mcode-path <file> を渡すか、MCODE_CLI を設定してください。リレーは実行したバージョンを result.json に記録します。
3. 対象の Git リポジトリ内にいるか、--cd でそのリポジトリを指定し、実行前に作業ツリーをクリーンにしておいてください。サンドボックスなしで実行する場合、クリーンな基準状態と比較できるほうがレビューしやすくなります。

一連の手順

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

1. 依頼内容を作成する

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

2. ディスパッチ

バンドルされたヘルパーを使って、簡潔な指示を MiniMax Code に送信します。ヘルパーは mcode exec をラップし、実行内容を記録して、構造化された result.json を書き込みます。そのため、あなたが行うことは「コマンドを実行し、ファイルを読む」だけです。以下の <skill-dir> は、このスキルがインストールされているディレクトリ、つまりこの SKILL.md があるフォルダーを指します。スキルを読み込んだディレクトリと同じです。Claude Code では、スキルの読み込み時に「このスキルのベースディレクトリ」として表示されます。他のオーケストレーターでは、同じディレクトリを使用してください。場所がわからない場合は、find ~ -name relay.mjs -path '*mcode-delegate*' を実行し、その一つ上のディレクトリに置き換えてください。

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# read-only (review/diagnosis; advisory):   add --read-only
# continue the exact session:               add --session <sessionId>  (from result.json; send only the delta brief)
# model / effort for this run:              add --model minimax/<model> --effort high
# hard time limit (watchdog):               add --timeout 2h  (default: off; implementation runs routinely need 1-2h)
# see all options:                          node .../relay.mjs --help

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

3. 完了を待つ

ヘルパーは MiniMax Code が完了するまで処理をブロックします。そのため、オーケストレーターが提供する機能を使い、処理が戻ったら再開してください。

• Claude Code: Bash 呼び出しを run_in_background: true で実行します。完了すると通知されます。
• 通常のシェル／その他のエージェント: 短いタスクの場合はフォアグラウンドで実行します。バックグラウンドで実行する場合は、結果ファイルをポーリングします。bash/zsh では … & を使い、その他のシェルでは同等の方法を使ってください。result.json が存在し、status が含まれていれば実行は完了です。（実行前の使用エラー、たとえば引数の誤りや指示が空の場合は、コード 2 と標準エラーのメッセージを出力して終了し、結果ファイルは書き込みません。そのため、終了コードも確認してください。mcode バイナリがない場合は 127 で終了しますが、status が mcode_unavailable の result.json は書き込みます。）

result.json が書き込まれ、プロセスが終了した時点で実行完了です。ステータス行ではなく、作業ツリーを確認してください。実装者の完全なレポートは result.json の finalMessage フィールドにあります（レポートのマーカーで囲まれた完全な内容が標準出力にも表示されます）。

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

result.json には、MiniMax Code 自身の要約とゲートに関する主張が含まれています。そのまま受け入れず、再検証してください。

• プロジェクトのゲートを自分で再実行します（手順 1 のテスト／lint／ビルドのコマンド）。「ゲートを通過した」という報告を決して鵜呑みにしないでください。
• 指示と照らし合わせて差分を確認します。依頼どおりに実行されているか、余計なこと（スコープの逸脱）も不足もないかを確認してください。結果の touchedFiles を出発点として確認します。サンドボックスがなかったため、指示で指定されたパスの内外を問わず、編集だけでなく削除も確認してください。
• インストールされている場合は、差分に対して関連するガードスキル（guard-skills の clean-code-guard、test-guard など）を実行します。このスキルが成果物を作り、それらのスキルが評価します。
• スキーマ／マイグレーションの変更は往復で検証し、削除の場合は参照が残っていないか grep で確認します。

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

5. 反映する

中継処理がコミットすることはありませんが、MiniMax Code による .git への書き込みは防げません。指示では実装者によるコミットを禁止しており、レビュー担当者は反映前に、HEAD と記録されたディスパッチ前のベースラインを比較します。**コミットするのはオーケストレーターです。**ゲートに合格し、差分に問題がないことを確認した後に限り、次の作業を行います。

• 検証済みの成果物を、明確なメッセージを付けて自分でコミットします。
• 変更が必要な場合は、前回の result.json にある sessionId を指定して --session <sessionId> とともに追加指示を送り、再度レビューします。

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

このリレーは、対立する立場からのセカンドオピニオンを得る手段にもなります。合意した点と、それぞれの立場を併記した争点を簡潔にまとめたブリーフを用意し、--read-only を指定して実行したうえで、各争点について MiniMax Code に主張を擁護するか譲歩するかを求めます。成果物は最終メッセージで提示され、ファイルには一切触れません。この読み取り専用状態はプロンプトによってのみ設定されるため、判定結果は毎回確認してください。readOnlyViolation: false は Git から認識できる検出器が変更を検知しなかったことを意味します（無視対象のパスやリポジトリ外のパスは対象外です）。true は変更を検知したことを意味し、null は git で判定できなかったことを意味します。セカンドオピニオンは、復元できる余裕のあるクリーンなツリーで実行してください。

承認モデル

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

参考資料

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