claude-handoff

Claude Handoff

このスキルは、明示的に承認された計画に基づき、現在のセッション内で読み取り専用の調査または実装を進行します。task-handoff は、新しい別のセッション用に、判断事項をすべて確定したファイルを書き出します。後で、または別の場所で続ける作業には task-handoff を使用してください。承認済みの計画を今すぐ実装するには、セッション内ハンドオフを使用してください。

スラッシュまたはドル記号による呼び出しですでにこれらの指示が与えられている場合は、その指示に従ってください。その場合、このスキルをスキルツール経由でもう一度呼び出さないでください。

まず契約に従い、その後、Claude Code のセッション内 Agent ワークフローを使って、計画中に調査し、承認された計画を実装してください。

契約

• ユーザーが明示的に呼び出した場合にのみ実行してください。要求された成果が調査結果、根拠、評価であり、リポジトリの変更や実装計画を求めていない場合は、タスクを調査のみとして分類してください。すべてのハンドオフは、どのホストモードでも実行できます。実装ハンドオフは、計画フェーズを経て、起動前にユーザーから明示的な承認を得る必要があります。
• 成果と重要な制約に変更がなければ、すでに承認された計画を再利用してください。明示的なユーザー指示は、スキルの既定値より優先されます。未解決の判断事項、またはその承認範囲外の操作についてのみ、再度確認してください。
• Claude が判断、最終計画、オーケストレーションを担います。タスクとリポジトリの根拠から、計画前に調査が有用だと判断できる場合に限り、読み取り専用の調査サブエージェントに調査を委任してください。
• 調査エージェントは根拠を集め、調査結果を報告します。ファイルを編集したり、設計を決定したり、計画を提示したりしてはいけません。
• 実装エージェントは、承認された計画の担当部分を調査、編集、検証します。再設計したり、別の計画を提示したりしてはいけません。
• 必要最小限で効果的なチームを編成してください。エージェントは1つでも構いません。分割によって所要時間、正確性、検証が大きく改善する場合にのみ、エージェントを追加してください。1回のハンドオフで実装エージェントを8つより多く使用してはいけません。
• チームを確定する前に、各作業概要の所要時間を見積もってください。およそ25～30分を超える可能性がある作業は、並列実行できる個別の担当範囲、または依存関係に応じた作業段階に分割してください。必要に応じて統合エージェントを追加してください。
• 調査エージェントは最大3つまでとし、安定した ID R1～R3 を割り当ててください。調査エージェントは、実装エージェント8つとは別に数えます。
• Claude 自身の作業は、オーケストレーション、整合性チェック、失敗への対処、および条件付きの仕上げに限定してください。
• フォアグラウンドまたはバックグラウンドでの実行は Claude Code に任せてください。エージェントの完了が確定するのは、ターミナルへの直接の結果またはエラー、あるいは後から届く完了または失敗の通知だけです。起動確認、ネイティブのタスク行、一定時間の無応答、表示された権限プロンプトでは、エージェントの完了は確定しません。必要なすべての最終結果が届いてから、作業段階を確認してください。
• ユーザーがモデルを明示的に指定した場合（例：Sonnet、Opus）は、指定範囲がより狭く限定されていない限り、それをすべての調査エージェントと実装エージェントに適用するオーケストレーション上の制約として扱ってください。その範囲内では、通常使用する Sonnet／Opus の選択に置き換えてはいけません。Agent ツールでそのモデルを起動できない場合は、互換性がないことを報告し、別のモデルに切り替える前に確認してください。
• 承認された成果を、初期マニフェストやその書き込み範囲ではなく、権限の境界として扱ってください。実装中に、成果の達成に必要なリポジトリ内の関連修正や根拠の変更が判明した場合、Claude はハンドオフの範囲を拡張できます。その必須作業のために、Claude は再確認せずに後続エージェントを起動できます。発見したサブエージェントは割り当てられた範囲内で作業を止め、根拠を返します。範囲の拡大、調整、委任は Claude が担います。
• 検証の範囲は、求められた成果に合わせてください。承認済みの計画で明示的に求められていない限り、検証の仕組み（ゲート、マニフェスト、チェックポイント、ハッシュ固定、ジャーナル、受領記録）を追加してはいけません。急ぐことや作業を切り上げることをユーザーが明示的に求めた場合は、任意の再確認と必須の仕上げ作業を省略してください。その場合は、検証済みの作業をコミットし、省略した項目や未検証の項目を報告してください。

$ARGUMENTS がある場合は、それをタスクとして使用してください。ない場合は、現在のユーザーリクエストを使用してください。タスクで別のスキルが指定されている場合は、コンパニオンスキルに従ってください。

コンパニオンスキル

この引き継ぎと併せて別のスキルを指定するタスク（たとえば、 run $fresh-eyes-sweep and delegate the implementation）は、複数のスキルを組み合わせるものです。作業内容はコンパニオンスキルが定めます。この引き継ぎでは、委任の手順を定めます。

• コンパニオンスキルを読み込み、Claude で調査、判断、計画の各フェーズを実行します。実質的に速くなる場合は、このスキルの調査エージェントに読み取り専用の調査を割り当てます。そのうえで、コンパニオンスキルの方法、調査結果、制約を引き継ぎ計画に反映します。スキル一覧にないコンパニオンスキルも、disable-model-invocation: true によりインストール済みでも非表示になっている場合があります。存在しないと判断する前に、~/.claude/skills/<name>/SKILL.md を直接読み込んでください。
• コンパニオンスキルの調査そのものが作業の大半を占める場合（リポジトリ全体または多数のファイルを対象とする監査や一斉修正など）、Claude はその範囲を把握して分割し、インラインで読み進めることはしません。計画の承認後、各実装エージェントがコンパニオンスキルのルールをブリーフに明記したうえで、担当範囲を監査し、修正します。
• この契約は、コンパニオンスキルと重複する計画承認、エージェント数の上限、安定 ID、検証担当者の一元化、および結果の各項目に優先します。また、失敗の分類、コミットの担当、完了報告にも優先します。コンパニオンスキルが独自のサブエージェント、検証、またはコミットの手順を定めていても、これらの優先ルールが適用されます。ただし、コンパニオンスキルのユーザー判断が必要なゲートは引き続き有効です。このスキルの計画承認を、該当するゲートの承認として扱います。計画のみを行うコンパニオンスキルでは、実装も依頼され、ユーザーが計画を承認した場合に限り、実装します。
• エージェントはスキルを読み込めません。「スキル X を使う」と指示してはなりません。必要なコンパニオンスキルの手順、規約、抜粋をブリーフに含めてください。
• コンパニオンスキルで $code-polish または $agents-brain maintain の実行が求められる場合、そのパスは計画フェーズで必須です。ただし、そのパスの実行は完了ごとに一度だけです。コンパニオンスキルのコミット指示によってコミットが追加されることはありません。
• 完了時には両方の契約を満たしてください。完了報告に加え、コンパニオンスキルが求める報告用成果物（台帳、表、判定結果など）も作成します。

調査フェーズ

調査のみのタスクでは、調査エージェントを1〜3人起動し、調査結果をまとめて返した時点で終了します。 このタスクでは、計画フェーズに進んだり、実装エージェントを起動したりしてはいけません。実装への引き継ぎでは、スコープが不明確な場合、複数または不慣れなサブシステムにまたがる場合、あるいは逐次的な証拠収集により大幅に時間がかかる場合に調査を実施します。実装への引き継ぎでは、調査エージェントを起動しないのがデフォルトです。起動数は、タスクとリポジトリの証拠に基づいてClaudeのみが決定します。ユーザーに参加の意思を尋ねたり、エージェントの指定を求めたりしてはいけません。

調査を実施する場合は、最大3人のエージェントにR1〜R3の固定IDを割り当てます。ユーザーがモデルの希望を示していない限り、subagent_type: "Explore"と明示的なモデルを指定して、Agentツールから直ちに起動します。希望が示されていない場合は、範囲の限られた調査にはsonnet、不慣れなサブシステムや複数のサブシステムにまたがる詳細な調査にはopusを使用します。modelを省略すると、セッションのモデルが継承されます。読み取り専用のExploreツールセットを使用するため、どのモードでもこの起動は許可されています。

ホストのPlan Modeで独自の調査・計画サブエージェントが指定されている場合、このスキルの調査エージェントが調査を担います。計画はClaude自身が作成し、計画サブエージェントは起動しません。

選定したエージェントはすべて、1つのメッセージで並列に起動します。続けて🔎 Research started — <n> agentsと投稿します。その後は、ネイティブのサブエージェント進捗表示に任せてください。ダッシュボードを作成してはいけません。

各エージェントには、未解決の疑問点、正確な調査範囲、タスクに関係するリポジトリ上の制約、読み取り専用の境界を含む、自己完結したプロンプトを渡します。調査の詳細度を指定するヒントも含めます（範囲の限られた調査にはmedium、複数のサブシステムにまたがる詳細な調査にはvery thorough）。ExploreはプロジェクトのCLAUDE.mdを読み込みません。これらの制約が暗黙的に伝わると想定してはいけません。調査結果、根拠、未解決の疑問点、阻害要因を報告するよう求めます。計画や設計を返すことは禁止します。

エージェントの作業がすべて完了したら、すべての結果を読み、調査結果と根拠を実装計画または調査のみの回答に反映します。スコープや進め方に影響する場合に限り、未解決の疑問点や阻害要因をAskUserQuestionで提示します。調査エージェントは何も変更しません。作業ツリーを調整してはいけません。変更を報告した結果は、契約違反として明示します。

Exploreエージェントは一度限りで、再利用可能なエージェントIDを返しません。Exploreエージェントに実装継続のルールを適用してはいけません。必要な根拠が不足している場合は、未解決の疑問点または阻害要因として扱います。

調査のみのタスクでは、証拠をまとめ、最後に### 🔎 Research handoff — <completed|blocked>を記載します。その後に、エージェント数、調査結果、根拠、未解決の疑問点、阻害要因を記載し、計画フェーズと完了報告に置き換えます。調査によって変更が必要だと判明した場合は、その旨を調査結果として報告して終了します。その場合、計画を作成したり編集に着手したりしてはいけません。

計画フェーズ

実装への引き継ぎの場合に限り、このフェーズに進みます。

委任による調査でもClaude自身による調査でも、ユーザーが明示した事実（数量、対象項目、アカウントなど）と矛盾する場合は、計画を作成する前にAskUserQuestionで確認します。その場合、調査結果に合わせて計画のデフォルトのスコープを広げてはいけません。

以下のセクションを含む、意思決定に必要な事項を網羅した計画を作成します。

## Claude Handoff

- Research: `<none | R1..Rn — key findings used>`
- Companion skills: `<none | $x — phases Claude runs / what is folded into briefs>`
- Strategy: `<sequential|parallel|hybrid>`
- Agents: `<1-8>` — `<why this is the smallest effective count>`
- Validation owner: `<agent-id|claude>` — `<aggregate checks it runs once>`

| Agent | Wave | Depends on | Scope              | Model            | Implementation brief                                   | Completion evidence                 |
| ----- | ---- | ---------- | ------------------ | ---------------- | ------------------------------------------------------ | ----------------------------------- |
| `A1`  | `1`  | `none`     | `<files/behavior>` | `<sonnet\|opus>` | `<outcome, edits, constraints, and stopping criteria>` | `<commands and observable results>` |

- Code polish: `<required|not required>` — `<reason>`
- Agent-context maintenance: `<required|not required>` — `<reason>`

マニフェストの各表セルは1行に収めます。概要にそれ以上の記述が必要な場合は、表の下にエージェントごとの見出しを設けて記載します。 計画を最終化する際は、すべてのマニフェスト書き込みスコープの和集合を、ai-coord draft --name <plan-slug> '<label>' '<path>'... で記録します。ディレクトリスコープの場合に限り、--recursive を使用します。<plan-slug> は計画の短い識別名（例：debarrel-lib）から作成します。小文字に変換し、[A-Za-z0-9._-] 以外の文字を - に置き換え、40 文字で切り詰めます。Git ルートが 2 つ以上ある場合は、ai-coord bundle draft --name <plan-slug> '<label>' '<absolute-path>'... を使用します。計画の「競合するエージェントを待つ」セクションには、正確な昇格コマンド ai-coord start --draft <plan-slug>（または ai-coord bundle start --draft <plan-slug>）を記載し、同じ和集合に対する明示的な ai-coord start '<label>' '<path>'... フォールバック（または ai-coord bundle start '<label>' '<absolute-path>'...）も残します。

新しい実装セッションがスコープを説明文から再構成せずに済むよう、これらのコマンドを計画そのものに含める必要があります。 フォールバックを使用するのは、昇格時に no draft named ... が報告された場合に限ります。名前付きドラフトは権限を付与せず、7 日後に期限切れになります。

リポジトリの根拠と承認済みの作業内容に基づいて、実行形態を選択します。

• 順次：あるエージェントが別のエージェントに依存する場合、書き込みスコープが重複する場合、または後続のエージェントが統合／集約検証を担当する場合。
• 並列：独立した作業のみで、書き込みスコープが明示的に重複しない場合。エージェントは共有コンテキストを調査できますが、担当スコープ外に書き込んではなりません。
• ハイブリッド：依存関係に沿ったウェーブ方式。各ウェーブ内の独立したエージェントを並列で実行し、ウェーブを調整してから、その依存先を開始します。

ウェーブは、最も時間のかかるエージェントが完了した時点で終了します。後回しにできる検証は、検証担当者に移します。並列作業だけでは計画の完了を証明できない場合は、統合と集約検証を行う後続の順次エージェントを確保します。

引き継ぎごとに、集約検証の担当者を必ず 1 名だけ割り当てます。パッケージ全体またはリポジトリ全体を対象とするチェック（テストスイート全体、パッケージ全体の型チェック／lint、カタログ全体のチェック）は 1 回だけ実行します。統合エージェントがいる場合は、そのエージェントが実行します。いない場合は、ウェーブ後の調整中に Claude が実行します。それ以外の各エージェントには、担当した変更のみを証明する最小範囲のチェックを、完了の証拠として要求します。これは、変更したファイルを対象とする lint／フォーマット／型チェックと、対象を絞ったテストです。

モデルの希望が明示されていない場合、各実装エージェントの作業内容に応じてモデルを選択します。

作業	モデル
範囲が限定的、定型的、または日常的な実装	sonnet
意味論に関わるもの、横断的なもの、または最も難しい実装：相互作用する不変条件や複雑なアルゴリズム推論を伴うもの	opus

sonnet と opus のエイリアスは、Anthropic API 上の Sonnet 5.5 と Opus 5.5 に対応します。Agent ツールでは呼び出しごとの effort を指定できません。サブエージェントはセッションの effort を引き継ぎます。すべてのエージェントは general-purpose サブエージェントタイプで実行されます。モデルの選択とスコープの分割は、ウェーブ全体のバランスを考慮します。

非局所的な不変条件、並行処理やステートマシン、マイグレーションや解析、認証やセキュリティ、リトライやエラーのセマンティクス、公開 API やデータ契約の変更がある場合は、$code-polish を必須にします。ファイル数だけを理由に必須とはしません。

承認済みの作業が、そのメンテナンスワークフローでサポートされている対象を変更する場合は、$agents-brain maintain を必須にします。対象は、README.md、AGENTS.md または CLAUDE.md、長期的に参照するコンテキストドキュメント、.agents/skills 配下にインストール済みの既存プロジェクトスキル、または事実関係の修正が文章のみに限られる skills/ 配下の既存の Git 管理対象ソースカタログスキルです。管理対象のエージェント設定ルートにあるインストール済みコピーは対象外です。両方の条件に該当する場合は、両方のパスを必須とします。どちらにも該当しない場合は、どちらも必須にしません。

ユーザーが計画を承認するまでは、実装サブエージェントを起動しないでください。読み取り専用の調査フェーズのみ、承認前に実行できます。

実行フェーズ

起動

実装サブエージェントを起動する前に、計画で指定されたドラフトを、記録されたコマンドで昇格させ、すべてのマニフェスト書き込みスコープの和集合をカバーする親所有の claim を取得します。昇格時に no draft named ... が報告された場合に限り、記録された明示的な開始時の代替手段を使用します。ファイルは個別に正確に指定し、ディレクトリスコープには --recursive を使用します。起動前に READY を必須とします。

昇格または開始がキューに入るかブロックされた場合、待機のためにターンを終了してはいけません。その場合は、Bash の run_in_background: true で ai-coord wait を実行し、その戻りによってセッションが再開するようにします。また、準備完了以外の再開イベント（メッセージ、不明なカバレッジ、作業の解放、既定の300秒タイムアウト）でも戻ります。再開のたびに、MESSAGE イベントを ai-coord inbox で処理します。記録された昇格または開始コマンドを再送し、再開のたびに古いブロッカーを診断します。

ネイティブサブエージェントは親セッションの ID を継承するため、その claim によって割り当てられた書き込みが許可されます。親がすべての調整ライフサイクルコマンドを所有し、調整、必要な仕上げ、コミットまでカバレッジを保持します。サブエージェントはライフサイクルコマンドを実行しません。委任ガードではこのルールを強制できません。Claude のサブエージェントは親のセッション ID を継承し、親と区別できません。そのため、サブエージェントのライフサイクルコマンドは親の claim に対して実行されます。

すべてのブリーフで、ライフサイクルコマンドを禁止してください。サブエージェントは決してそれらを実行してはいけません。

各エージェントは Agent ツールを使って起動します。subagent_type: "general-purpose"、マニフェスト行に記載されたモデル、A1 — <scope> のような説明を指定します。並列ウェーブのエージェントはすべて、同じメッセージ内で並列ツール呼び出しとして起動します。逐次エージェントは、依存関係を調整した後にのみ起動します。Claude Code はサブエージェントの進捗をネイティブに表示します。独自のダッシュボード、ポーリングループ、ステータステーブルは作成しないでください。

起動後、🚀 Handoff started — <agent count> agents · <strategy> · <wave count> waves という簡潔な行を1つ投稿します。その後はネイティブの進捗表示に任せます。許可された継続処理のため、実装結果が完了するたびに返されたエージェント ID を記録します。

サブエージェントには計画時の会話が一切共有されません。各エージェント向けに、自己完結型で成果を優先したプロンプトを作成し、以下を含めます。

1. 承認済みの全体的な成果に加え、そのエージェントの実装概要、依存関係、完了を示す証拠。
2. 正確な書き込み範囲、関連するリポジトリの制約、既知の未コミット変更の境界（他のエージェントやセッションが同じツリーを共有している場合があります）、および前提となるエージェントの結果。
3. Plan フェーズの検証担当者ルールに従った検証の割り当て：実行が必要な、スコープ内のチェック。担当者以外のすべてのエージェントについて、ウェーブ終了後に担当者が一度だけ実行する集約チェックは実行してはならないことを明記します。承認済みの計画に含まれていない検証の仕組みを新たに指示してはなりません。
4. マニフェストの規模と、ユーザーまたはアダプターが定めた実行時間のハードリミットに合った所要時間の見積もり。ソフトな見積もりだけでは停止条件になりません。ブロックされた場合は、部分的な証拠と、具体的な阻害要因または到達したハードリミットを報告します。
5. 次の権限の境界：調査、スコープ内での編集、ローカルでの検証を行います。リポジトリまたはホストの指示が速やかなコミットを推奨していても、コミット、プッシュ、デプロイ、外部への書き込み、スコープの拡大は一切行いません。コミットは、照合後にオーケストレーターが行います。
6. オーケストレーションを行うセッションのラベルまたはセッション ID のプレフィックスを明記した、委任コンテキストに関する説明：そのセッションによる割り当て範囲の要求または存在は、競合ではなく、その範囲を承認するものです。兄弟サブエージェントの重複しないスコープも競合ではありません。エージェントに割り当てられたファイルそのものを、無関係なセッションが要求している場合に限り、blocked と報告します。
7. 次の停止ルール：承認済みの計画を正確に実装します。実行不可能な場合や再設計が必要な場合は、代替計画を提示せず、証拠を添えてブロック状態を報告します。最終結果または実際の阻害要因だけをもって終了します。次の手順を告げる進捗概要、継続の申し出、マイルストーンの報告、または何もブロックしていない判断を最後に記してはなりません。
8. 最終メッセージを、次のフィールドだけで終える要件：status（completed／blocked）、summary、changed files（実際に変更したファイルのみ）、verification（実行したすべてのコマンドとその結果）、residual risks、blockers。

完全性を保てる範囲で、各プロンプトを簡潔にします。共通の成果概要に加え、そのエージェント固有の概要、スコープ、制約を含めます。エージェントごとに計画全文を繰り返してはなりません。

収集

エージェントから返答があったら、必須の結果フィールドを確認し、changed files を作業後の正式なスコープとして扱います。報告されたファイルが存在すること、または意図的に削除されていることを確認します。スコープ内に収まっていることも確認します。検証の証拠が、Plan フェーズの検証担当者ルールに基づく割り当てと一致することを確認します。各ウェーブの後、無関係な並行変更を含めずに、マニフェストと作業ツリーをもとにすべての結果を照合します。ワーカーの反応が遅い、またはないという理由だけで、エージェントを追加したり、モデル、スコープ、検証担当を変更したりしてはなりません。

後続作業が見つかった場合は、「完了」以下の手順に従って処理します。Claude が検証担当者の場合、この照合時に割り当てられた集約チェックを一度だけ実行します。集約チェックの失敗を阻害要因とみなす前に、その原因を特定します。まず、引き継ぎによる変更、フォーマッター、フック、ジェネレーターの影響を除外します。引き継ぎの書き込みスコープ外にある下流ファイルでの失敗も含めて確認します。失敗が無関係であり、引き継ぎに割り当てられたチェックが引き続き成功することを証拠で確認できた場合に限り、失敗があっても作業を続けます。

予期しないスコープ外の編集、同一の並列ウェーブにおけるエージェント間のスコープ重複、または引き継ぎの変更に起因する集約チェックの失敗は、阻害要因です。これらの阻害要因がある場合、依存する作業や仕上げ作業を開始してはなりません。実装を黙って引き継いではなりません。

スキルの進化に関するレビュー

引き継ぎ中に使用したスキルに対する、検証済みの修正は、以下の任意のレビューとは分けて扱ってください。ユーザーまたはリポジトリの指示ですでに修正が認められている場合、その完了の責任は親エージェントにあります。サブエージェントは書き込み範囲を広げず、根拠を報告します。検証済みの箇所が1つあれば十分です。メインタスクがブロックされていても、独立した修正は妨げられません。引き継ぎで必要な作業を完了するか、ブロッカーを特定してから、適用されるメンテナンスポリシーに従い、最終報告の前に独立した修正を完了してください。プランモードでは引き続き編集が禁止されます。

必要なエージェントがすべて正常に完了し、タスクの検証も済んだ後で、Claude だけが、そのタスクによって、今後も繰り返される可能性が高いと合理的に判断できる、安定した再利用可能なワークフローが明らかになったかどうかを判断します。このレビューで、エージェントがスキルの進化に関する変更を提案してはなりません。ブロック、失敗、または一部のみ完了した引き継ぎでは、このレビューを行わないでください。一度限りの作業、まれな例外、付随的なクリーンアップ、推測に基づく価値は対象外です。規模や難易度だけでは、再発性の根拠になりません。

新しいスキルを提案する場合は、配置先がリポジトリ内か、グローバルの ~/projects/agent-skills かを明記してください。既存スキルの改訂を提案する場合は、変更が必要なスキルをすべて正確に列挙してください。この基準を満たす提案がある場合は、既存の完了報告に簡潔な提案を最大1件（短い文2つ以内）追記してください。その提案では報告の形式を変更せず、次のアクションとして $task-handoff を提示してください。このレビューで $task-handoff を自動的に呼び出したり、スキルを新規作成または改訂したりしてはなりません。該当するものがない場合は、何も記載しないでください。プレースホルダーや「該当なし」という注記も不要です。

完了

• status: blocked の場合、または完了した作業によって、承認済みの成果に必要な関連リポジトリ内の修正や根拠の変更が判明した場合、それを新たな承認が必要な作業ではなく、契約の承認境界ルールに基づく後続作業として扱います。その作業については、すでに開始している独立したエージェントの完了を待ち、依存するエージェントの実行は保留します。必要最小限の範囲でマニフェストを拡張します。その範囲についてリポジトリの調整要件を満たしてから、新規または既存のエージェントを起動します。成果が完了するか、実際の承認境界に達するまで繰り返します。

  安定したID、依存関係の順序、エージェント数の上限（8人）、集約検証の担当者1人を維持します。後続作業を担当したエージェントも、最終的な人数と報告に含めます。

• 完了報告の前に、承認済みの成果が対象とする同じパターンの箇所をすべて修正します。これらの箇所を任意の項目や対象範囲外の項目として列挙してはなりません。

• 継続によって承認済みの成果が変わる場合、実質的な再設計や無関係な作業が必要になる場合、または既存の確認境界（破壊的な操作、購入、デプロイ、外部への書き込み）を越える場合に限り、ユーザーに確認します。実装を黙って引き継いだり、別のモデルに変更することだけを理由に再起動したりしてはなりません。関連する完了済みの成果は、依存するエージェントに渡します。

• Agent ツールの呼び出しエラー、または必須フィールドが欠けた最終メッセージは、インフラストラクチャの障害として扱います。作業が未完了のまま止まった進捗報告も含まれます。この障害が発生した場合は、git status／git diff でエージェントの書き込み範囲に部分的な編集がないか確認します。その後、返されたエージェント ID を宛先にして SendMessage で同じエージェントを1回だけ続行させます。部分編集されたファイルを明記し、以前のコンテキストを保ったまま、短い確認・続行メッセージを送ります。これは再試行であり、8人の上限に対する新しいエージェントではありません。

  エージェント ID が返されなかった場合、または続行に失敗した場合、そのエージェントはブロックされたものとします。以下の停滞時の例外に該当する場合を除き、再起動してはなりません。例外は、ハーネスの停滞（例：Agent stalled: no progress for 600s）が発生し、その書き込み範囲に変更がないことが git status／git diff で確認された場合に適用されます。この場合は、同じ指示で、新規エージェントとして正確に1回だけ再起動できます。これは8人の上限には含めません。

• 必須の各エージェントが完了したら、報告された変更ファイルを統合して重複を除き、統合した検証証拠によって承認済みの計画が裏付けられていることを確認します。

• 必須のエージェントに失敗があった場合、またはユーザーが明示的に急ぐよう求めた場合や作業の完了を求めた場合は、予定していた仕上げのパスをすべて省略し、その旨を報告します。それ以外の場合は、統合した変更ファイルのうち各パスに該当するものだけを指定して、必須の各パスを1回ずつ実行します。順序は、まず $code-polish（デフォルトの simplify-then-review モード）、次に該当するコンテキスト対象を指定した $agents-brain maintain です。該当するパスが1つだけなら、そのパスだけを実行します。いずれのパスにも統合した変更ファイル以外を指定せず、各パスが定めるワークフローの権限を超えて範囲を広げさせないでください。

• 各仕上げパスが実際に変更した対象範囲内のファイルを、最終的な変更ファイル一覧と検証内容に反映します。必須のパスが処理を停止する、失敗する、またはサポート対象外の範囲に書き込む場合、後続の仕上げ作業とリポジトリ横断コミットを停止します。

• 承認済みの作業によって、引き継ぎを開始したリポジトリ以外の Git リポジトリが変更された場合は、それぞれの追加リポジトリで作業、検証、必須の仕上げが完了した時点で、自動的に各リポジトリから $commit を1回実行し、そのリポジトリで変更されたファイルのみを対象にします。これらのコミットでは個別の確認を省略します。不完全、停止中、想定外、または対象範囲外の変更は決してコミットしないでください。依頼または常時適用されるユーザー指示で許可されている場合は、プッシュします。

• 引き継ぎでコミットをプッシュし、リポジトリに .github/workflows などの CI ワークフローが定義されている場合、完了報告の前にプッシュした HEAD の実行状況を確認します（gh run list --commit <sha> を実行し、続いて gh run watch <run-id> を実行します。ホストが対応している場合はバックグラウンドで実行します）。引き継ぎに起因する失敗は後続作業として修正し、CI の結果を報告します。変更したコードの動作がプラットフォームによって異なり、ローカル検査が1つのプラットフォームしか対象にしていない場合は、未検証のプラットフォームをリスクとして明記します。

• ### 🏁 Claude handoff — <completed or blocked> で締めくくり、戦略とエージェント数を記載し、エージェントごとの簡潔な結果表を続けます。その後に ### 📦 Changed をファイルツリー形式で記載し、### 🧪 Verification、実行した場合は ### 🧹 Polish、該当する場合はリポジトリ横断コミットのハッシュ、問題や注意事項がある場合は ### Issues and caveats を続けます。各仕上げパスとその結果を記載し、該当するその他の空欄には none と記載します。必須作業が失敗した場合は ⛔ blocked を使用します。パス、コマンド、ハッシュ、サブエージェントの戻り値フィールドは、正確な表記のまま装飾せずに記載します。

• 問題と注意事項は Resolved（証拠で確認済みの修正）と Open（影響と次の手順を添えた未解決の問題、制限、または未検証の前提）に分類します。空のグループは省略し、両方とも空の場合はセクション全体を省略します。各項目は1回だけ報告します。中立的な背景情報や合意済みの決定は、変更または範囲の項目に記載します。必須作業を妨げるものに限って blocker を使用し、具体的に起こり得る悪影響には risk を使用します。回避策があっても、根本的な問題が結果に影響している場合は未解決として記載します。