muse-delegate

Muse Delegate

あなたはオーケストレーターです。このスキルを使うと、範囲を限定したコーディングタスクを別の実装者である Muse Code（muse）に任せ、その成果をレビューして自分で反映できます。ブリーフを作成し、判断を担うのはあなたです。Muse は独自の exec 実行でコードを書き、あなたが検証してコミットします。

ここに記載する内容は、特定のオーケストレーションエージェントに限定されません。このフローに必要なのはシェルコマンドの実行とファイルの読み取りだけなので、その2つの機能があれば、どのエージェントでも進行できます。委任 → レビュー → コミットの一連の流れは、オーケストレーターに Claude Code を使って実行済みです。ほかのオーケストレーターについては、まだ実証されていません。

使用しない場合

• タスクが小さく、その場で実行できる場合。委任に伴うオーバーヘッドに見合いません。
• muse CLI がインストールされていない、または認証されていない場合（muse login を実行するか、META_API_KEY を設定してください）。
• 自分でコードを書きたい場合。
• ネイティブ Windows を使用していて、サポート対象のランチャーが必要な場合。上流の muse ランチャーは Darwin/Linux のみ対応しています。このスキルは Windows の互換性マトリックスにも含まれていますが、Windows での実際のディスパッチは、サポート対象の Muse インストールではありません。

初回のディスパッチ前に読むこと：自律性モデル

ヘッドレス Muse で使うのは**muse exec のみ**です。muse resume は対話型 TUI であり、呼び出すことはありません。 --resume-last は拒否されます。実行を継続するには --session <id>（Muse の --session-id）を使います。

書き込みを行う実行では、Muse のサンドボックスを有効のままにし、--disable-approval を渡して、ヘッドレス実行がツール承認プロンプトで停止しないようにします。また、--trust-workspace と --user-input-auto-resolve も渡します。これは --yolo でも --full-access でもありません。どちらもデフォルトとして勝手に指定しないでください。--trust-workspace を指定すると、対象リポジトリのルールとスキルが実装者の実行環境に読み込まれます。また、リレーによってサンドボックス内の実装者のツールセットが制限されることはありません。タスクの範囲を限定するのはブリーフです。

--read-only を指定すると、--disable-write（シェル以外のファイルシステムへの書き込みを無効化）と**--disable-shell**が追加されます。レビューもプロンプトで停止しないよう、承認は無効のままです。

--provider echo|meta は、テストと明示的なプローブに使うリレー専用のフラグです。フリート全体の切り替えには使いません。

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

1. muse --version が成功すること。成功しない場合は、Muse Code をインストールして muse login を実行します（または META_API_KEY をエクスポートします）。
2. どの muse が PATH 上にあるかを確認します。 command -v muse で有効なランチャーを確認できます。リレーは、実行したバージョンを result.json に記録します。
3. 対象の Git リポジトリ内にいること（または --cd でそのリポジトリを指定すること）。

実装者モデルを選ぶ

Muse には設定済みのデフォルトモデルがあるため、新しい実行では --model を省略できます。カタログ ID を固定する必要がある場合は、--model またはモデルを設定するフリートの --lane を渡してください。再開した --session の実行では、セッションのモデルを維持するために --model を省略します。利用可能なモデルのセットを人間が指定していない場合は、従量課金の ID を推測する前に確認してください。

詳しくは、references/writing-the-brief.md を参照してください。

フロー

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

1. ブリーフを作成する

Muse に見えるのは、あなたが送るテキストと作業ツリーから読み取れる内容のみです。チャット履歴や共有コンテキストはありません。タスクに必要な情報をすべてブリーフに記載します。目標、現状、変更する内容、変更しない内容、プロジェクトの実際のゲートコマンド（リポジトリの AGENTS.md／CLAUDE.md／Makefile から確認し、推測しないでください）、レポートの形式を含めます。Muse には、コミットはしない（あなたが行う）と伝えます。ブリーフ1つにつきタスクは1つにします。詳細なガイダンスとテンプレートについては、references/writing-the-brief.md を参照してください。

2. ディスパッチ

同梱のヘルパーを使って、概要を Muse に送信します。このヘルパーは muse exec --json --prompt-file をラップし、実行結果を取得して、構造化された result.json を書き込みます。（以下の <skill-dir> は、このスキルがインストールされているディレクトリ、つまりこの SKILL.md が格納されているフォルダーです。）

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# optional model:                           add --model <id>
# fleet lane from delegate-setup:           add --lane <name>  (dials apply; flags still win)
# reasoning intensity:                      add --effort none|minimal|low|medium|high|xhigh|max|ultra
# read-only (no non-shell writes, no shell): add --read-only
# continue a specific Muse session:         add --session <id>  (delta brief only; no --resume-last)
# hard time limit (watchdog):               add --timeout 2h  (default: off; implementation runs routinely need 1-2h)
# see all options:                          node .../relay.mjs --help

ヘルパーは一時ディレクトリに成果物を書き込むため、レビュー対象のリポジトリは変更されません。コミットは決して行いません。手順 5 を参照してください。仕組み、フラグ、result.json の形式については、次を参照してください。 references/dispatch-and-poll.md。

3. 完了を待つ

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

• Claude Code： run_in_background: true を指定して Bash 呼び出しを実行します。完了すると通知されます。
• 通常のシェル／その他のエージェント： 短いタスクの場合はフォアグラウンドで実行し、そうでなければバックグラウンドで実行して結果ファイルをポーリングします。result.json が status を含んで存在すれば、実行は完了です。（実行前の使用エラー（引数の誤りや概要が空の場合）は、終了コード 2 で終了し、結果ファイルは書き込まれません。そのため、終了コードも確認してください。muse バイナリが見つからない場合は終了コード 127 で終了しますが、ステータスが muse_unavailable の result.json は書き込まれます。--resume-last は使用エラーです。ヘッドレスで再開するには --session <id> を指定します。）

進捗トラッカーを実際の状況より優先しないでください。result.json が書き込まれ、プロセスが終了した時点で実行は完了です。Muse は run.terminal.completed イベントがなくても終了コード 0 で終了することがあります。この場合、リレーは completed ではなく failed と報告します。実装者の完全なレポートは result.json の finalMessage フィールドにあります（レポートマーカーに挟まれた形で、標準出力にも全文が表示されます）。

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

Muse の result.json には、最終メッセージと、各種ゲートに関する申告が含まれています。必ず再検証し、鵜呑みにしないでください。

• プロジェクトのゲートを自分で再実行してください（手順 1 に記載されているテスト／lint／ビルドコマンド）。「ゲートを通過した」という申告を決して鵜呑みにしないでください。
• 概要と照らして差分を確認してください。 Muse は依頼どおりに、余計な変更（スコープの拡大）も不足もなく実装していますか？ result の touchedFiles を確認の出発点にしてください。
• 利用可能であれば、差分に関連するガードスキル（guard-skills の clean-code-guard、test-guard など）を実行してください。このスキルが成果物を作り、それらのスキルが評価します。
• スキーマ／マイグレーションの変更は往復テストを行い、削除については参照切れがないか grep で確認してください。

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

5. 反映

実装者は作業ツリーを編集し、コミットはオーケストレーターが行います。 作業を検証した担当者がコミットするべきです。ゲートに合格し、差分に問題がないことを確認した後にのみ、次を行ってください。

• 検証済みの作業を自分でコミットし、明確なメッセージを付けます。
• 変更が必要な場合は、--session <id> を使って追加分の概要を送り（タスク全体を繰り返さないでください）、再度レビューします。ヘッドレスでの --resume-last はありません。

承認モデル

委任は、人間が選択して行うものです。人間が「このキューを実行して」「進めて」と承認した後は、検証済みでゲートに合格した作業をコミットすることが合意された契約です。それが委任の目的です。この権限には 2 つの制限があります。明らかにし、内々に処理しない（Muse の設計上の判断、妥当ではあるものの依頼されていない変更、ブロッキングではない細かな指摘は、黙って受け入れるのではなく報告する）こと、そしてスコープの変更が必要な場合は停止する（正しく完了するために概要の範囲を超える必要がある場合は、権限を独自に拡大せず、確認を求める）ことです。詳しくは references/review-and-land.md を参照してください。

参考資料

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