codex-handoff

Codex Handoff

Codex-handoff は、現在のセッション内で読み取り専用の調査を行うか、依頼された作業の計画と実装を調整します。 Task-handoff は、新しい別のセッション用に、判断事項をすべて解決したファイルを作成します。作業を後で、または 別の場所で続ける場合に使用してください。依頼された作業を今すぐ実装するには、セッション内ハンドオフスキルを使用してください。

スラッシュまたはドル記号による呼び出しですでに会話にこれらの指示が含まれている場合は、その指示に従ってください。その 場合は、スキルツールからこのスキルを再度呼び出さないでください。

以下の共通契約に従い、ホストアダプターを1つだけ選択して、ホスト固有のすべての操作に使用してください。

ホストの選択

環境変数、プロセスの親子関係、ユーザーが指定したホスト名ではなく、呼び出し可能なオーケストレーションツールを確認してください。

• spawn_agent、wait_agent、send_message、followup_task が利用可能な場合：references/codex-cli-host.md を 最後まで読んでください。
• それ以外で、Claude Code の Agent ツールと Bash ツールが利用可能な場合：references/claude-code-host.md を最後まで読んでください。
• どちらも利用できない場合：互換性エラーで停止してください。Codex ホストでは、ネイティブの Codex マルチエージェントサポートが必須です。ネストされた Codex CLI プロセスへのフォールバックは決して行わないでください。

ホスト固有のすべての操作には、アダプターを1つだけ使用してください。起動、進捗、再試行、権限、結果の受け渡しに関する仕組みを、両方のアダプターから読み込んだり、組み合わせたりしないでください。アダプターはホストの仕組みやマニフェストの設定を個別に定められますが、この共通契約を緩和することはできません。

契約

• 明示的に呼び出された場合にのみ実行します。求められる成果が調査結果、証拠、評価であり、リポジトリの変更や計画が求められていないタスクは、調査のみと分類します。すべての引き継ぎは、どのホストモードでも実行できます。実装の引き継ぎは計画フェーズを経てから開始し、別途ユーザーの承認を求める手順は挟みません。
• 実装依頼は、その成果に向けて計画、委任、完了する権限を与えるものとして扱います。成果と重要な制約が変わらない場合は、既存の計画を再利用します。明示的なユーザー指示は、スキルの既定値より優先されます。このスキルの外部から課されるホストの計画モードの制限と確認要件を守ります。必要な入力が不足している場合、または操作が既存の権限を超える場合に限り、質問します。
• 親が意思決定、最終計画、オーケストレーションを担います。計画前の段階で有用な場合に限り、タスクとリポジトリの証拠に基づく調査を読み取り専用の調査エージェントに委任します。
• 調査エージェントは証拠を集め、調査結果のみを報告します。ファイルの編集、設計上の決定、計画の提示は行いません。
• 実装エージェントは、確定済み計画の割り当てられた部分を調査、編集、検証します。設計をやり直したり、別の計画を提示したりしません。
• 効果を得るために必要な最小限の実装チームを編成します。エージェントが1人でもかまいません。分割によって所要時間、正確性、検証のいずれかが大きく改善する場合に限り、エージェントを追加します。実装エージェントは合計8人を超えてはなりません。
• チームを確定する前に、各依頼の所要時間を見積もります。およそ25～30分を超える見込みの依頼は、1人のエージェントにまとめて任せず、互いに独立した範囲または依存関係のある段階に分割して並行して進めます。必要に応じて統合エージェントを追加します。
• 調査エージェントは最大3人とし、安定したID R1～R3 を割り当てます。調査エージェントは実装エージェント8人とは別に数えます。
• 親自身の実装作業は、オーケストレーション、整合性チェック、失敗への対処、必要に応じた仕上げの工程に限ります。
• ユーザーがモデルを明示的に指定した場合（例：GPT-6 Luna）、指定の範囲がより限定されていない限り、その指定をすべての調査エージェントと実装エージェントに適用するオーケストレーション上の制約として扱います。その範囲内では、アダプターが通常選択するLuna／Sol／Astraに置き換えてはなりません。ホストがそのモデルを起動できない場合は、互換性がないことを報告し、代替モデルへの切り替え前に確認を求めます。
• 求められる成果を権限の境界として扱い、最初のマニフェストやその書き込み範囲を境界とはしません。実装中に、その成果に必要な関連リポジトリ内の修正や証拠の変更が判明した場合、親は引き継ぎ範囲を拡張できます。新たに判明した範囲について、親は改めて確認を求めずに後続のエージェントを起動できます。必要性を見つけたワーカーは、割り当てられた範囲で作業を止め、証拠を報告します。範囲の拡張、リポジトリ内の調整、委任は親が担います。
• 検証の範囲は、求められる成果に合わせます。確定済み計画で明示的に求められていない限り、検証の仕組み（ゲート、マニフェスト、チェックポイント、ハッシュの固定、ジャーナル、受領記録）を追加してはなりません。ユーザーが明示的に急ぐよう求めた場合や、作業の終了を指示した場合は、任意の再チェックと必須の仕上げ工程を省略できます。その場合は、検証済みの作業をコミットし、省略した内容や未検証の内容を報告します。

$ARGUMENTS がある場合は、それをタスクとして使用します。それ以外の場合は、現在のユーザー依頼を使用します。別のスキルを指定するタスクには「関連スキル」が適用されます。

連携スキル

この引き継ぎとともに別のスキルを指定するタスク（たとえば、 run $fresh-eyes-sweep and delegate the implementation）は、複数のスキルを組み合わせるものです。作業内容は連携スキルが定義し、 この引き継ぎでは委任の仕組みを扱います。

• 連携スキルを読み込み、親エージェントでその調査、判断、計画の各フェーズを実行します。大幅に効率化できる場合は、このスキルの調査エージェントを通じて読み取り専用の調査を行います。その後、連携スキルの手法、調査結果、制約を引き継ぎ計画に反映します。ホストのスキル一覧に連携スキルが見当たらなくても、disable-model-invocation: true によって非表示になっているだけで、インストール済みの場合があります。存在しないと結論づける前に、ホストのスキルルートから SKILL.md を直接読み込みます（Claude Code では ~/.claude/skills/<name>/SKILL.md、Codex では ~/.agents/skills/<name>/SKILL.md）。
• 連携スキルの調査が作業の大半を占める場合、親エージェントは調査内容をインラインで読むのではなく、作業範囲を割り当てて分担します。リポジトリ全体や大量のファイルを対象とする監査や一斉確認などが該当します。計画後、各実装エージェントはブリーフに記載された連携スキルのルールに従って、自分の担当範囲を監査し、修正します。
• この契約は、連携スキルと重複する計画承認、エージェント数の制限、固定 ID、単一の検証担当者、結果フィールドに関する指示に優先します。また、失敗の分類、コミットの担当、完了報告に関する指示にも優先します。連携スキルが独自のサブエージェント、検証、コミットの手順を定めている場合も、これらの優先規則が適用されます。ただし、既存の指示だけでは解決できない、ユーザーの判断を要する実質的なゲートは引き続き適用されます。連携スキルが定める通常の計画承認手順は繰り返しません。計画のみを行う連携スキルでは、実装も求められており、かつホストが書き込みを許可している場合に限り実装します。
• エージェントはスキルを読み込めません。エージェントに「スキル X を使う」と名前を挙げて指示してはいけません。必要な連携スキルの指示、規約、抜粋をブリーフにインラインで記載します。
• $code-polish または $agents-brain maintain の実行を連携スキルが求める場合、その工程は計画フェーズで必須です。この工程は完了ごとに1回実行します。連携スキルのコミットに関する指示によって、コミットが追加されることはありません。
• 完了時には両方の契約を満たします。選択したアダプターの完了報告に加え、連携スキルが求める報告成果物（台帳、表、判定結果）も作成します。

調査フェーズ

調査のみのタスクでは、調査エージェントを1～3人起動し、調査結果を統合して返した時点で終了してください。 そのタスクでは、計画フェーズに進んだり、実装エージェントを起動したりしてはいけません。実装への引き継ぎでは、範囲が不明確な場合、複数のサブシステムまたは不慣れなサブシステムにまたがる場合、あるいは必要な証拠を順番に集めると親エージェントの作業が大幅に遅くなる場合に、調査を実施してください。実装への引き継ぎでは、調査エージェントを起動しないことがデフォルトです。調査エージェントの人数は、タスクとリポジトリの証拠に基づいて親エージェントのみが決定します。ユーザーに参加の可否を尋ねたり、エージェントの指定を求めたりしないでください。

調査の作業をただちに開始するか、そのまま計画に進んでください。

調査を実施する場合は、エージェントに R1～R3 の固定IDを割り当て、選択したアダプターの読み取り専用の仕組みを通じてただちに起動してください。各エージェントには、以下を含む自己完結したプロンプトを渡してください。

• 未解決の質問と、調査範囲の明確な指定。
• 関連するリポジトリの制約と、把握している並行作業の範囲。
• 厳格な読み取り専用の権限境界。
• 計画や設計ではなく、証拠を返すことを求める停止ルール。
• 作業時間の上限と、それを使い切るよう指示すること。時間のみを理由にした早すぎる blocked の報告は、有効な停止ではありません。
• 結果の正確なフィールド名：status、findings、open_questions、evidence、blockers。

調査エージェントが、作業時間の大半を残したまま具体的な障害を示さず、時間のみを理由に blocked を返した場合、そのエージェントの調査範囲は確定していません。また、未調査の範囲のパスを証拠に記載したまま completed を返した場合も、調査範囲は確定していません。いずれの場合も、未調査のファイルと残りの作業時間を指定し、アダプターの同一エージェント継続の仕組みを使って、同じエージェントの作業を1回継続してください。これは新たな調査エージェントには数えません。

必要な調査エージェントすべての作業が確定したら、その調査結果と証拠を実装計画または調査のみの応答に反映してください。範囲やアプローチに影響する場合に限り、ホストのユーザー質問の仕組みを使って、未解決の質問や障害を示してください。作業ツリーの調整は行わないでください。調査エージェントは何も変更しません。編集が報告された場合は、契約違反です。

調査のみのタスクでは、証拠をまとめ、### 🔎 Research handoff — <completed|blocked>、エージェント数、調査結果、証拠、未解決の質問、障害を含めて終了してください。これは計画フェーズと、選択したアダプターの実装完了報告に代わるものです。調査の結果、変更が必要だと判明した場合は、その内容を調査結果として報告し、終了してください。その場合、実装計画を作成したり、編集を開始したりしないでください。

計画フェーズ

実装の引き継ぎを行う場合に限り、このフェーズに入ります。

調査（委任によるものか、親エージェント自身によるものかを問いません）が、ユーザーが明示した事実（数量、対象項目、アカウントなど）と矛盾する場合は、計画を作成する前にホストのユーザー質問機能を使って確認してください。その場合、調査結果に合わせて計画の既定の範囲を広げてはいけません。

次のセクションと、選択したアダプターの正確なマニフェスト表を含む、意思決定を完了できる計画を作成してください。

## Codex Handoff

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

<host-adapter manifest table>

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

計画の最終調整時に、すべてのマニフェスト書き込みスコープの和集合を、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 日後に期限切れとなります。

リポジトリの証拠と依頼された作業に基づいて、実行形態を選択してください。

• 順次：あるエージェントが別のエージェントに依存する場合、書き込みスコープが重複する場合、または後続のエージェントが統合や全体検証を担当する場合。
• 並列：独立した作業のみを対象とし、書き込みスコープを明示的に分離します。エージェントは共有コンテキストを調査してもかまいませんが、割り当てられたスコープ外に書き込んではいけません。
• ハイブリッド：依存関係に沿ってウェーブを構成します。各ウェーブ内では独立したエージェントを並列実行し、ウェーブ全体を調整してから依存するエージェントを開始します。

ウェーブは、最も時間のかかるエージェントが完了した時点で完了します。最上位ティアのエージェントのスコープは最小限に抑え、後回しにできる検証は検証担当者に移します。並列作業だけでは計画全体を実証できない場合は、統合と全体検証を担う後続の順次エージェントを確保します。引き継ぎ全体を通して、安定したエージェント ID と明示的な依存関係を指定してください。

全体検証の担当者は 1 人だけにしてください。パッケージ全体またはリポジトリ全体を対象とするチェックは 1 回だけ実行します。統合エージェントがいる場合は、そのエージェントが実行します。いない場合は、親エージェントがウェーブ後の調整時に実行します。他のエージェントは、自身の変更を実証するために必要な最小限のチェックのみを実行します。たとえば、ファイル単位のフォーマット、リンター、型チェックと対象を絞ったテストなどです。

非局所的な不変条件、並行処理または状態機械、マイグレーションまたは解析、認証またはセキュリティ、再試行またはエラーのセマンティクス、公開 API またはデータ契約の変更には、$code-polish を必須としてください。ファイル数だけを理由に必須としてはいけません。

依頼された作業によって、その保守ワークフローがサポートする対象が変更される場合は、$agents-brain maintain を必須としてください。対象は、README.md、AGENTS.md または CLAUDE.md、永続的なコンテキスト文書、プロジェクトにインストール済みの既存スキル（.agents/skills 内）、または事実関係の修正が文章のみで済む、Git で追跡されている既存のソースカタログスキル（skills/ 内）です。管理対象のエージェント設定ルートにあるインストール済みコピーは対象外です。両方のトリガールールに該当する場合は、両方の実行が必須であることを明記してください。どちらにも該当しない場合は、どちらも必須としません。

計画を進捗報告として提示し、そのまま調整と実装の開始に進んでください。計画の承認を求めてターンを終了してはいけません。ユーザーが計画のみを求めた場合、またはホストが書き込みを禁止している場合は、計画の提示後に終了してください。

実装プロンプトの契約

すべての実装エージェント向けに、自己完結型で成果を最優先するプロンプトを作成します。以下を含めてください。

1. 求められる全体的な成果と、エージェントの実装概要、依存関係、完了を示す証拠。
2. 正確な書き込み範囲、関連するリポジトリの制約、既知の未コミット変更の境界、前提となるエージェントの結果。
3. Plan Phase の単一の検証担当者に基づく、エージェントごとの検証割り当て：実行する範囲を限定したチェックと、検証担当でない場合は集約チェックを実行してはならないこと。確定した計画にない新たな検証手段を割り当ててはなりません。
4. マニフェストの規模見積もり、およびユーザーまたはアダプターが課すハード実行時間制限に合致した進行の見積もり。ソフトな見積もりだけでは停止条件になりません。作業が妨げられた場合は、部分的な証拠と、具体的な阻害要因または超過したハード制限を報告してください。
5. 次の権限境界：調査し、割り当てられた範囲内だけを編集し、ローカルで検証すること。リポジトリやホストの指示でプロンプトのコミットが推奨されていても、コミット、プッシュ、デプロイ、外部への書き込み、範囲の拡大は決して行わないでください。調整後に親がコミットします。
6. 選択されたアダプターの委任および調整のコンテキスト。親セッションと範囲が重ならない兄弟エージェントが競合する作業ではない理由、およびどのような無関係な範囲の重複申告があれば blocked を返すべきかを含めてください。委任先は調整ライフサイクルコマンドを実行してはなりません。これらのコマンドは終了コード 64 で拒否されます。許可するのは ai-coord status、ai-coord touched、ai-coord inbox、ai-coord msg、ai-coord finding のみです。
7. 次の停止ルール：確定した計画をそのまま実装してください。実行不可能な場合や再設計が必要な場合は、代替計画を提案するのではなく、証拠を添えて blocked を返してください。許可された作業が残っている限り、進捗更新後も続行してください。マイルストーン、続行の申し出、または対応不要な判断事項の一覧は、完了した結果ではありません。
8. すべての結果フィールドを返す要件：status（completed または blocked）、summary、実際に変更したファイルのみを列挙する changed_files、すべてのコマンドとその結果を列挙する verification、residual_risks、blockers。

完全性を保てる範囲で、各エージェントのプロンプトは簡潔にしてください。全体で共有する成果の概要に加え、そのエージェント固有の作業概要、範囲、制約のみを含めます。各エージェントに計画全体の文面を繰り返してはなりません。

この契約を繰り返さずに、選択されたアダプターのコマンド、権限、トランスポート、ホストツールに関する制約を追加してください。

実行と整合性確認

実装の第 1 ウェーブを開始する前に、親は計画で指定されたドラフトを昇格させ、完全なマニフェストの書き込みスコープの和集合を取得します。 記録された明示的な開始時のフォールバックは、昇格時に no draft named ... が報告された場合にのみ使用します。エージェントを起動する前に READY を必須とします。昇格または開始がキューに追加されたりブロックされたりした場合、待機するためにターンを終了してはいけません。その場合は、 アダプターの待機メカニズムを使って ai-coord wait を実行します。

また、メッセージ、不明なカバレッジ、作業の解放、デフォルトの 300 秒のタイムアウトなど、準備完了以外のウェイクイベントでも戻ります。 ウェイクのたびに、MESSAGE イベントを ai-coord inbox で処理し、記録された昇格または開始コマンドを再送信して、古いブロッカーを診断します。

選択したアダプターを通じて、計画された戦略と依存関係のウェーブに従ってエージェントを起動します。作業者の反応が遅かったり静かだったりするという理由だけで、 エージェントを追加したり、モデル、作業量、スコープ、検証担当を変更したりしてはいけません。完了した作業によって、依頼された成果に含まれる未計画の前提条件が判明した場合は、 マニフェストを改訂し、対象を絞った追加エージェントを起動してください。安定した ID、依存関係の順序、8 エージェントの上限、集約検証の担当者 1 名を維持します。 追加エージェントも最終的な件数と報告に含めます。

完了した各エージェントについて、共有結果の全フィールドがそろっていることを必須とします。changed_files を、エージェントの作業後のスコープを示す権威ある情報として扱います。 報告されたファイルが存在するか、意図的に削除されていること、スコープ内にあること、割り当てに対応する検証証跡があることを確認します。 関連する完了済みの結果を依存先のエージェントに渡します。

各実装ウェーブの後、無関係な同時進行の変更を混ぜずに、すべての結果を現在のマニフェストおよび確認できる作業ツリーと照合します。親が検証を担当する場合は、 この照合作業中に割り当てられた集約チェックを 1 回実行します。ブロックする前に、集約チェックの失敗が何に起因するかを判断します。まず、引き継いだ作業の変更、 フォーマッター、フック、ジェネレーターの影響を除外します。これには、書き込みスコープ外の下流ファイルでの失敗も含まれます。証拠によって無関係だと確認でき、 引き継いだ作業自体のチェックにも合格している場合に限り、失敗を越えて続行します。

予期しないスコープ外の編集、同一ウェーブ内の競合、または引き継いだ作業が原因の失敗はブロッカーです。その場合、依存先の起動や仕上げの作業を開始せず、 実装を黙って引き継いではいけません。

失敗の分類

• status: blocked の結果が、依頼された成果に必要な、作業者のスコープ外にあるリポジトリ内の関連する修正または証拠の変更を示している場合、 それは契約のスコープ拡張権限の範囲内の追加作業です。新たな承認は必要ありません。すでに開始した独立エージェントは完了させます。 依存先は保留します。必要最小限のスコープでマニフェストを拡張し、そのスコープに対するリポジトリの調整手順を満たします。

  新規または再利用した実装エージェントを起動します。成果が完成するか、実質的な承認境界に達するまで繰り返します。

• 続行によって依頼された成果が変わる場合、大幅な再設計や無関係な作業が必要になる場合、または破壊的操作、購入、デプロイ、外部への書き込みなど既存の確認境界を越える場合にのみ、ユーザーに確認します。 実装を黙って引き継いだり、より大きなモデルを使うためだけに再起動したりしてはいけません。

• ツールまたはインフラストラクチャの障害は、アダプター固有の証拠によってその分類が裏付けられる場合にのみ、再試行可能として扱います。 まず部分的な編集を確認します。その後、アダプターの同一エージェント向けメカニズムを使って、検証と続行をちょうど 1 回試みます。 これは 8 エージェントの上限に数える新規エージェントではありません。インフラストラクチャ障害が 2 回目に発生した場合、そのエージェントと依存先をブロックします。

• 通常のタイムアウト、返されたブロッカー、無応答、タスクレベルの検証失敗を、インフラストラクチャ障害として分類してはいけません。独立していると確認された作業のみ続行します。

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

引き継ぎ中に使用したスキルへの検証済みの修正は、以下の任意のレビューとは分けて扱います。ユーザーまたはリポジトリの指示ですでに修正が許可されている場合、完了の責任は親にあります。サブエージェントは、書き込み範囲を広げずに証拠を報告します。検証済みの事例は1件で十分です。また、メインタスクがブロックされていても、独立した修正を妨げるものではありません。

引き継ぎで必要な作業を完了するか、その阻害要因を特定してください。その後、適用されるメンテナンスポリシーに従って、最終報告の前に独立した修正を完了してください。Plan Modeでは、引き続き編集が禁止されています。

必要なエージェントがすべて成功し、タスクが検証された後に限り、親のみがスキル進化の機会を判断します。引き継ぎがブロックされた場合、失敗した場合、または一部しか完了していない場合は、決して行いません。エージェントは推奨を行いません。安定して再利用でき、今後も繰り返し発生する可能性が十分に高いワークフローのみを推奨してください。単発の作業、まれな例外対応、付随的な整理、価値が不確かな提案は除外してください。新しいスキルを提案する場合は、リポジトリ内とグローバルな ~/projects/agent-skills のどちらに置くかを明記してください。改訂を提案する場合は、対象となるスキル名とその理由を明記してください。

提案がこの基準を満たす場合は、アダプターの既存の完了報告に、簡潔な提案を最大1件（短文2文以内）追記してください。形式は変更しないでください。その後、次のアクションとして $task-handoff を提示してください。レビュー中に $task-handoff を自動実行したり、何かを新規作成または改訂したりしてはいけません。該当するものがない場合は、プレースホルダーも付けず、何も記載しないでください。

完了

• 必須エージェントがすべて完了した後、報告された changed_files の和集合から重複を除き、統合された検証エビデンスによって最終化された計画が証明されていることを確認します。

• 完了報告の前に、Failure Classification に従って後続エージェントを通じて、依頼された成果の対象となる同じパターンの残りの箇所を修正します。これらを任意項目や対象外項目として挙げてはいけません。

• 必須エージェントが失敗した場合、またはユーザーから急ぐよう明示的に依頼された場合や、作業を切り上げるよう依頼された場合は、予定していたすべての仕上げパスを省略し、その旨を報告します。それ以外の場合は、和集合に含まれる該当パスのみを指定して、必要な各パスを一度ずつ実行します。まず $code-polish をデフォルトの簡素化してからレビューするモードで実行し、次に $agents-brain maintain を対象となるコンテキスト対象で実行します。必要なパスが一つだけの場合は、一つだけ実行します。いずれのパスにも和集合に含まれないパスを指定せず、宣言されたワークフローの権限を超えて作業範囲を広げさせてはいけません。

• 各仕上げパスで実際に変更された対象範囲内のファイルを、最終的な変更ファイル一覧と検証結果に反映します。必須の仕上げパスがブロックされた場合、失敗した場合、またはサポート対象範囲外に書き込みを行った場合は、以降の仕上げパスとリポジトリをまたぐコミットを中止します。

• 依頼された作業によって、このマシン上で引き継ぎを開始したリポジトリ以外のリポジトリも変更された場合は、各追加リポジトリで作業、検証、必要な仕上げが完了した後、そのリポジトリから $commit を呼び出し、そこで変更されたファイルに範囲を限定します。不完全な変更、ブロックされた変更、予期しない変更、対象範囲外の変更はコミットしてはいけません。依頼または継続的なユーザー指示で許可されている場合は、プッシュします。

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

• 選択したアダプターの完了報告で締めくくります。戦略、ウェーブ数とエージェント数、各エージェントに依頼した設定、ステータス、概要を含めます。統合した変更ファイルと検証結果も記載します。仕上げを実施した場合は、各パスとその結果を列挙します。自動的にリポジトリをまたいでコミットした場合はコミットハッシュを含め、「Issues and caveats」がある場合はその項目も含めます。その他、該当する空の項目には none と記載します。マシンの結果ペイロードを公開してはいけません。

• 問題と注意点は、Resolved（エビデンスで検証済みの修正）と Open（影響と次の手順を含む、残存する問題、制約、または未検証の前提）に分類します。空のグループと、すべて空の場合のセクション全体は省略します。各項目は一度だけ報告します。中立的な背景情報と合意済みの判断は、変更内容または対象範囲に記載します。blocker は必須作業を妨げるものに限り、risk は具体的な悪影響の可能性に限ります。

  回避策を講じても、根本的な問題が引き続き結果に影響する場合、その項目は未解決のままです。