review-fix-address-bots

ボットをレビューし、修正し、対応する

以下のフェーズを順番に実行します。判断、編集、ワークスペースを変更するコマンド、検証、Git、PR の変更、ボットへの返信を担うのは、プライマリエージェントのみです。

不変条件

• レビュアーは助言のみを行い、厳密に読み取り専用とします。ファイル、差分、履歴、テスト、既存の出力は調査できますが、ファイルや Git／PR の状態を変更したり、テスト、ビルド、パッケージスクリプト、ジェネレーター、または任意のリポジトリコマンドを実行したり、実装を委任したりしてはなりません。
• すべてのレビュアーへのプロンプトに、次の境界を含めてください。「読み取り専用モードで作業してください。あなたは助言のみを行います。ワークスペースや Git／PR の状態を変更したり、コミットやプッシュを行ったりしないでください。調査結果と批評をプライマリエージェントに返してください。最終判断はプライマリエージェントが行います。」
• 無関係なユーザーの変更を保持してください。汚れたワークツリーをきれいにするために、reset、自動 stash、広範囲のステージング、履歴の書き換え、チェックポイントコミットを決して使用しないでください。
• ログ記録は観測目的です。失敗した場合は、その失敗を報告して安全なワークフローを続行してください。テレメトリーを理由に、コード、判断、Git／PR の状態、ループの上限を変更してはなりません。
• scripts/review-run-log.mjs は不透明な実行ファイルとして扱ってください。このワークフロー中にソースを読むことは決してしないでください。文書化されたコマンドと、templates、--help、Markdown のリファレンスを使用してください。ユーザーからヘルパーのデバッグまたは変更を明示的に依頼された場合に限り、そのソースを調査または変更してください。

1. 統合済みの対象を準備する

1. リポジトリの指示と、該当する実装スキルを確認します。ブランチ、状態、対象、リモート、アップストリーム、PR の状態、初期状態の汚れたワークツリーに関する所有権の境界を記録します。プッシュ前に、対象ブランチではない名前付きブランチであることを必須とします。明示的な許可がない限り、ブランチ名を変更したり、デフォルトブランチをプッシュしたりしてはなりません。
2. ユーザーのレビュー用プロンプトを使用します。要求されたカスタムプロンプトを利用できない場合は、作業を停止してプロンプトを求めます。レビュー用プロンプトの指定がない場合に限り、references/review-guidelines.md を読みます。
3. このスキルのディレクトリを特定し、レビュー作業を始める前に node <skill-dir>/scripts/review-run-log.mjs templates を実行して標準ペイロードを取得し、解決済みのコホートと上限を指定して start を実行します。.context に logPath を保持し、重要な状態遷移とレビュアーの呼び出しをすべて追記します。ヘルパーが記録を拒否した場合、ログ記録の拡張が必要な場合、またはテレメトリーの挙動を診断する必要がある場合に限り、references/run-logging.md を読みます。
4. コミット済み、ステージ済み、未ステージの変更と、関連する未追跡ファイルをまとめて調査します。Conductor のワークスペース差分を優先してください。それが利用できない場合は、マージベースから HEAD までの差分、git diff HEAD、git status --short、関連する未追跡ファイルを調査します。実装には無関係なユーザー作業を含めないでください。
5. PR の実際のベースブランチとリポジトリのリモートを特定します。PR がない場合は、リポジトリの設定を使用します。ベースを明示的にフェッチし、その参照と SHA を記録します。git pull は使用しないでください。フェッチした SHA が HEAD の祖先でない場合は、正式なレビューの前に統合します。デフォルトでは明示的なマージを行います。リベースは、必要な場合または要求された場合に限り行い、許可なく公開済みの履歴を書き換えてはなりません。
6. 既存のステージ済み変更をマージコミットに含めないでください。汚れたワークツリーによって安全に統合できない場合は、作業を停止します。両方のブランチの意図、周辺コード、テストを踏まえて競合を解決します。重要な製品、UX、パブリック API、またはアーキテクチャ上の選択については、ユーザーに確認を求めます。競合解決を含む統合済みのツリーをレビュー対象とします。レビュー開始後に統合が行われた場合は、すべてのレポートを無効にし、コホートを再実行します。
7. 最初にプッシュする前に、PR が存在せず、ボットのフェーズで PR が必要な場合は、PR を作成する権限があることを確認します。権限がない場合は、リモートを変更する前に作業を停止します。

レビュアーセッション

ユーザーが明示的に指定したレビュアーの人数、モデルの組み合わせ、推論レベルを使用してください。指定がない場合は、すべての初回パスと修正パスに、次のデフォルトのレビュアー構成を使用してください。

Reviewer ID	Model	Reasoning
sol-1	gpt-5.6-sol	high
terra-1	gpt-5.6-terra	xhigh
luna-1	gpt-5.6-luna	max
luna-2	gpt-5.6-luna	xhigh
luna-3	gpt-5.6-luna	xhigh

人数が1人から5人の場合は、この順序で使用してください。別の組み合わせが明示されている場合は、モデルのティアと1から始まる序数に基づいて安定したIDを割り当ててください。人数が5人を超え、組み合わせが指定されていない場合は、組み合わせを確認してください。決定的な検出のため、タスク名をsol-1からsol_1の形式に正規化してください。生のレビュープロンプト、対象のフィンガープリント、役割の境界、サービスティアは構成員全員で同一にし、各レビュアーには割り当てられた推論レベルを使用してください。同時実行数の上限を超える場合は、対象を編集せずにキューへ追加してください。

パケット

このスキル、参考資料、ヘルパーコマンド、実行ログの詳細、または主要な会話をレビュアーに送ってはいけません。各レビュアーには、レビュータスクのみを含む、同一の自己完結型パケットを渡してください。パケットには、生のユーザープロンプト（またはデフォルトの基準）、対象のSHAとワークスペースのフィンガープリント、関連するスコープ／差分またはパス、該当する場合は競合の概要、読み取り専用の境界、必要な指摘の形式（ファイル、最小限の行範囲、重大度、シナリオ、根拠）を含めてください。他のレビュアーの指摘、主要担当者の結論、修正方針、テレメトリの指示は含めないでください。

起動と検証

すべての初回レビュアーを、fork_turns: "none"、自己完結型のパケット、指定されたモデルと推論レベルで起動してください。主要な会話をフォークしてはいけません。ランタイムが、実際に適用された設定と、安定して再開可能なハンドルを公開する必要があります。指定した引数だけでなく、ランタイムの証拠に基づいて適用済みの設定を検証してください。

ランタイムが許す場合は、並行して起動してください。エフェメラルなレビュアーは決して使用しないでください。コントロールの検証に失敗した場合は、編集を中止し、ステータスをblockedとして終了してください。指定した引数だけを検証とみなしてはいけません。ハンドルが利用可能になった時点でreviewer_session_startedを記録し、永続化された検証の後に限りreviewer_session_controls_verifiedを記録してください。完了したタスクのdurationMsは、ランタイムが公開している場合にのみ記録してください。

停滞したワーカーを監視、復旧、終了する

各待機時間（デフォルトは30秒）の後に、コホートウォッチャーを実行します。これは最大ポーリング間隔であり、実行時間の下限ではありません。完了したらすぐに処理してください。

node scripts/review-run-log.mjs inspect-reviewers \
  --log "$REVIEW_RUN_LOG" \
  --stale-after-ms 120000 \
  --soft-deadline-ms 600000 \
  --hard-deadline-ms 1200000 \
  --hard-deadline-ms-by-model '{"gpt-5.6-luna":1800000}' \
  --record

ソフト期限は警告です。デフォルトのハード期限は20分で、Luna のレビュアーは30分です。ハード期限は、現在の task_started（存在しない場合はセッション開始時刻）から開始します。レビュアーを失敗と判定する前に、正確に対応する永続化済みセッションを調べてください。active、stalled、および in_progress の結果が1件あることは失敗ではありません。ウォッチャーはワーカーを中断しません。

ハード期限を超過したレビュアーについては、すぐに正確に対応するセッションをもう一度調べます。まだ終端状態でなければ、調査で得た nativeHandle を使って agents.interrupt_agent を呼び出します。永続化済みの sessionId は決して使わないでください。agents.list_agents で停止したことを確認し、その後、レビュアー ID、永続化済みセッション ID、ネイティブハンドル、フェーズ、理由、適用した期限を含めて reviewer_session_cancelled を追記します。広範囲な強制終了を行ったり、別のレビュアーを中断したり、初回レビューにフォローアップを行ったりしてはいけません。初回レビューの再試行は、sol_1_retry_1 のような別のタスク名を使用できますが、レビュアー ID は sol-1 のままにします。

その再試行もハード期限を超過した場合は、レビュアーを再試行不可としてマークし、継続性確認と修正から除外します。完了したレビューはすべて保持し、それらのレビュアーでワークフローを続行します。実行は partial となりますが、タイムアウトだけを理由に編集をブロックしたり、レビュアーの指摘を破棄したりしてはいけません。初回レビューを完了したレビュアーがいない場合、または別の安全性や完全性に関する条件によって続行できない場合に限り、ブロックします。継続性確認セッションがハード期限を超過した場合は、正確なハンドルを終了した後に、コホート全体の再起動ルールに従います。

結果が見つからない場合や読み取れない場合は、再試行する前に正確に対応するセッションを調べてください。

node scripts/review-run-log.mjs inspect-native-session --log "$REVIEW_RUN_LOG" --reviewer-id "$REVIEWER_ID" --stale-after-ms 120000

復旧した結果は、レビュアーハンドル、リポジトリ、適用された制御、および完了した最終回答イベントのそれぞれに正確に1件ずつ一致する必要があります。復旧した回答を使用しますが、レビュー本文を記録してはいけません。調査結果が unavailable の場合に限り、前述のハード期限のクリーンアップ手順に従って再試行してください。未加工の結果は実行ログの外に保管し、簡潔な観察結果と処理結果だけを記録します。

セッションの継続性を維持する

修正を始める前に、安定したレビュアー ID、要求した制御と適用した制御、レビュアーハンドル、初回フィンガープリント、継続状態を含む、Git で無視される .context/reviewer-sessions.json 台帳を作成します。認証情報、プロンプト、レビュー本文は決して保存しないでください。編集前に、初回レビューを完了したすべてのセッションを、元の制御と読み取り専用の境界を維持して再開します。必要な応答は SESSION_CONTINUITY_OK のみです。再試行不可のレビュアーは再開せず、除外対象として記録します。タスクの完了にかかった時間が取得可能な場合は記録してください。必要なハンドシェイクが1つでも失敗した場合は、すべてのレポートを破棄し、変更されていない対象に対してコホート全体を一度だけ再起動します。2回目も失敗した場合は、編集をブロックします。修正には、継続性が確認されたハンドルのみを使用します。

2. 独立した初回レビューを実施する

1. ユーザーが要求したレビュー担当群、または上記の既定のレビュー担当群を確定し、最後まで固定します。実行環境で、要求／適用されたモデル、推論レベル、または永続的なハンドルを正確に検証できない場合は停止します。黙って別のものに置き換えてはいけません。
2. 各レビュアーに、自己完結した同一の生のプロンプト、対象の SHA とフィンガープリント、競合の概要、役割の境界を提示します。他のレビュアーの調査結果やプライマリエージェントの結論は開示しません。すべての指摘について、ファイル、最小限の行範囲、重大度、シナリオ、根拠を明記するよう求めます。
3. HEAD、ステージ済み／未ステージの差分、ステータス、関連する未追跡ファイルの内容をフィンガープリント化します。初回報告と継続性チェックがすべて完了するまで、対象を変更しません。可能な場合は並行して開始し、残りは内容を変更せずにキューへ登録します。上記の開始、ウォッチドッグ、復旧、厳密な期限後のクリーンアップのルールを適用します。
4. 上記の正式なフィールドを使って、各開始、制御の検証、観察、キャンセル、完了または失敗したレビューを記録します。レビュアー ID と指摘 ID は安定したものを使用します。実際のトークン使用量と durationMs は、取得できる場合に限り記録します。
5. 期限への対応後、少なくとも1件の初回レビューを完了するよう求めます。編集前に、完了した各レビュアーに対して上記の継続性プロトコルを適用します。継続性を確認できなかったレビュアーがいても、他のレビュアーのレビューは無効になりません。
6. ハンドシェイク後に対象のフィンガープリントを検証します。予期しない変更があった場合は所有者を調査し、安定した対象に対してレビュー担当群全体を1回だけ再実行します。不安定な状態が繰り返される場合はブロッカーとして扱います。

3. 指摘を検証して修正する

1. 欠陥単位で重複を除去しつつ、報告したレビュアー／モデルは保持します。すべての主張を、現在のコード、テスト、規約に照らして独自に確認します。
2. 各指摘を valid、duplicate、already_fixed_or_stale、false_positive、out_of_scope_user_change、needs_user_decision のいずれかに分類し、安定した ID と処理結果を記録します。
3. スコープ内の有効な問題をすべて修正し、実用的な場合は焦点を絞った回帰テストを追加し、対象を限定したチェックを実行したうえで、変更後の差分全体をセルフレビューします。重要なプロダクト、UX、パブリック API、アーキテクチャに関する判断を推測で行わず、必要に応じてユーザーに確認します。

4. 修正内容についてレビュアーのレビューを再開する

継続性を確認できたすべてのセッションを、元の制御設定と読み取り専用の境界を維持して再開します。ユーザーの許可なしに、一時的なセッションや置き換え用のセッションを使用してはいけません。

1. ワークスペースを凍結し、フィンガープリント化します。各レビュアーに、更新後の差分と、すべての指摘、分類、証拠、変更または却下の理由、テスト、これまでの異議をまとめた累積台帳を提示します。
2. 根本原因が修正されているか、回帰や関連ケースが残っていないか、実質的により単純で範囲を限定した解決策があるか、テストで不具合をカバーしているか、却下した指摘を再検討すべきかを尋ねます。対応可能な異議では、具体的な障害シナリオ、影響を受けるコード、または明確に優れた範囲限定の代替案を示す必要があります。
3. 各回答を独立して判断します。是正ラウンドは最大3回とし、すべてのレビュアーが修正を妥当と判断するか、残る異議に証拠に基づく処理結果が付くまで継続します。有効な異議があれば、対象範囲を拡大します。第1ラウンドでは焦点を絞った修正／呼び出し箇所、第2ラウンドでは関連モジュールの境界／統合、第3ラウンドではサブシステムの不変条件／設計上の代替案／カバレッジの不足を確認します。
4. 指摘がないレビューや再試行も含め、すべてのレビューを記録します。各レビュー後にフィンガープリントを検証します。レビュアーが状態を変更した場合、プライマリエージェントはその変更のみを安全に元に戻し、報告を破棄して、読み取り専用で1回だけ再試行します。再度の変更はブロッカーとして扱います。

5. 検証、コミット、プッシュ

1. 担当ファイルまたはハンクのみをステージングし、ステージング済みの差分を確認します。
2. 最終検証は次の順序で行います。明示的なユーザー指示、リポジトリ／CI の指示、それらがない場合は、packageManager またはロックファイルで指定されたパッケージマネージャーを使い、変更したワークスペースのスクリプトを実行します。precommit があれば実行し、なければ利用可能な lint と test をそれぞれ実行します。JavaScript 以外のプロジェクトでは、文書化された CI 相当のチェックを実行し、確認範囲に含められないものがあれば報告します。コマンドを推測して実行してはいけません。
3. リポジトリのワークフローに沿ってコミットし、各プッシュの前に、コミット後の正確なツリーに対して最終検証を実行します。意図されたツール生成の変更を取り込み、変更を加えた後は検証を再実行します。ブランチが原因の失敗は、無関係な作業を変更せずに診断します。検証に失敗するツリーはプッシュしてはいけません。
4. 担当範囲を確認します。プッシュの直前に、PR 番号、UTC のレビュー期間のタイムスタンプ、コミット SHA を .context に記録します。失敗した場合は記録を更新します。ブランチ名を変更せずにプッシュし、PR の head が検証済みの SHA と一致することを確認します。

6. レビューボットの対応を完了する

1. リポジトリの address-review-bots スキルを解決して読み込みます。他のワークスペースのパスをハードコードしてはいけません。PR が記録済みのブランチと SHA を引き続き対象としていることを確認し、対応している場合はプッシュ時刻を渡します。
2. その SHA に対するすべての要求済みボットの応答を待ちます。レビューがない場合やタイムアウトした場合は、問題なしではなく不明として扱います。予期しない head の変更があれば、担当範囲を照合します。
3. 実質的な指摘をすべて分類し、妥当で対応可能かつリスクの低い整理上の指摘を修正して、セルフレビュー、コミット、最終検証、プッシュを行います。問題なしとなるか、判断が必要になるか、指定されたループ上限に達するか、チェックがタイムアウトするまで、address-review-bots に従って繰り返します。

完了と報告

実行がブロックされた場合や失敗した場合も、必ず finish を試みます。その際、イベントから得られたレビュアー／指摘に加え、実際のボット、検証、ステータス、SHA の結果を使用します。残りの完了済みレビュアーでワークフローを遂行できたものの、上限に達したレビュアーを除外した場合は partial を使用します。ワークフローを実際に停止させた状況に限り、blocked または failed を使用します。--collect-codex-usage を指定します。収集はレビュアーごとに行われるため、別のワーカーが利用できなくても、完了済みセッションの実際のトークン数、コスト、所要時間は集計されます。

レビュアーのトークン数と正確な所要時間の両方が欠けている場合は、diagnose-codex-usage を実行します。修復可能なセッションまたは台帳の不整合は修正します。ただし、使用状況の計測値を埋めるためだけに、上限に達したレビュアーを再起動してはいけません。使用状況セクションは、計測データのゲートを通過した場合に限り、report で生成します。通過しない場合は、生成された表を省略し、対象から除外したレビュアーと完了済みレビュアーのカバレッジを、値を捏造せずに報告します。モデルの比較は、1 回の実行における観察結果として扱います。

適用したコホート／制御、永続セッションと継続性／再試行、上限に達したレビュアー、ログパスとそこから導出した呼び出し／ラウンド／使用状況のカバレッジ、共通／固有の指摘とモデル比較、ベース SHA／統合／競合、すべての指摘の処置、修正ラウンドと意見の相違、プッシュごとの検証、コミット／PR、ボットループの結果、残るブロッカーを報告します。report は計測データが不完全なコホートを拒否するため、成功した場合に限り、その表をそのまま追加します。価格や計測に関する但し書きは追加してはいけません。Estimated cost は Total の直後に置き、Agent time を最後に置きます。その後に何も追加してはいけません。

リソース

• references/review-guidelines.md：既定のレビュー基準。
• references/run-logging.md：ロガーのトラブルシューティング、拡張、メトリクスの仕様。
• scripts/review-run-log.mjs：正式なペイロード、追記専用ログ、メトリクス、最終レポート。