review-fix

修正レビュー

解決済みのレビュー方針に基づき、問題がなくなるまでレビューラウンドを実行します。

/review-fix [target] [free-form review brief]

例：

/review-fix
/review-fix #123
/review-fix over-engineering
/review-fix #123 specification compliance and authorization boundaries
/review-fix ponytail-review and ask-exemplar

明示的なブリーフがある場合はレビュー方針を選択し、ブリーフがない場合はデフォルトのレビュー方針を使用します。このスキルは、レビュアーのオーケストレーション、エビデンスの検証、修正、チェックを担当します。

リクエストを解決する

先頭の引数は、既存の Git 参照、現在のリポジトリ内の PR または MR 番号、あるいは PR または MR の URL として明確に解決できる場合に限り、対象として扱います。それ以外の場合は、現在のブランチと作業ツリーを対象として使用し、引数全体をレビュー ブリーフとして扱います。

明示的な対象を、未コミットの作業を損なわずに編集可能なローカルチェックアウトへ解決します。安全にチェックアウトできない対象の場合、結果は incomplete になります。対象のベースは、フォージのメタデータ、アップストリーム、リポジトリのデフォルトブランチの順に特定します。

リクエストにブリーフが含まれない場合は、以下のデフォルトのレビュー方針を使用します。これは /review-fix #123 のような、対象のみのリクエストにも適用されます。

レビュー方針を解決する

レビューリクエストは、レポートのみを行うレビュー役として実行されます。リーフレビュー スキルは役割を1つ持ち、複合レビュー スキルは必須の観点と統合を含みます。オーケストレーターはすべての役割を直接スケジュールし、複合レビューの統合を実施します。これらのスケジュール規則は、呼び出されたスキルに含まれる委任や新規エージェントの要件より優先されます。レビュー基準と必須レポートは変更されません。

• 明示的に指定されたレビュー スキルごとに、1つのレビューリクエストを作成します。
• 明示的に指定されたスキルは、デフォルトのレビュー方針に追加するのではなく、置き換えます。
• プリフライト中に、指定された各スキルを読み込みます。書き込みや外部への変更を行わずにリクエストを完了できるリーフおよび複合レビュー スキルを受け入れます。循環するスキル、および必須の下位スキルを解決できない、またはレポートのみの実行に保てないスキルは却下します。
• スキルが指定されていない場合は、ブリーフをインストール済みのレビュー スキルと照合します。明確に一致するものが1つならそのスキルを使用し、一致するものがなければブリーフからアドホックレビュアーを1人作成します。妥当な候補が複数ある場合は、ネイティブの構造化入力で1つを選択する必要があります。選択が済むまでレビュアーを開始せず、対象も変更しません。呼び出し元が複数のレビューリクエストを明示的に求めた場合に限り、複数スキルのパネルを提示します。
• スキルを指定していないブリーフに複数の懸念事項が含まれていても、アドホックのレビューリクエストは1つのままです。文章を暗黙のパネルに分割してはいけません。
• 明示的に指定されたスキル名の前後のテキストは、それらのリクエストを補足します。別個の未割り当ての懸念事項が明確に追加されている場合は、それが指定されたレビュアーの担当か、別のアドホックレビュアーの担当かを確認します。

レビュアーを開始する前に、すべてのレビュー役についてプリフライトを行います。指定されたスキルと、その必須レビュー スキルを絶対ディレクトリに解決し、モデル呼び出しが無効でも各エージェントが自身のスキルを直接読み込めるようにします。モデルと推論の労力はランタイムが選択します。このスキルにはモデルマトリックスはありません。

レビュアーをスケジュールする

レビューの役割ごとに個別のレポートを必須とします。個別のエージェントスレッドは必須ではありません。 利用可能な容量とライフサイクルツールを確認し、上限のあるプール内で役割を割り当てます。レビュー担当者は調査して報告し、委任するのはオーケストレーターのみです。

• 完了したスレッドを終了できる場合は、新しいレビュー担当者を優先します。最終レポートを受け取り、利用可能なライフサイクルツールでスレッドを終了してから、担当者を入れ替えます。完了または中断だけでは、枠が解放された証拠になりません。
• 終了できない場合は、アイドル状態のレビュー担当者を後続タスクで順次再利用します。各割り当てには、その担当者の役割、現在のスナップショット、基準、レポートのみを行うという制約を明記します。新たにソースを調査して報告するよう求めます。以前の結論は、権威ある見解ではなく、検証すべき証拠として扱います。保持されたコンテキストと独立性の低下を開示し、再利用した担当者を新規担当者と呼ばないでください。
• 容量不足で拒否された場合は、未提出のレポートを回収し、アイドル状態のレビュー担当者を再利用します。容量またはライフサイクルの状態が変わった後に限り、生成を再試行します。必須の役割を遂行できるレビュー担当者がいない場合は、incomplete を返します。容量不足を理由に役割を省略してはなりません。

役割とエージェントの対応関係、プールの最大サイズ、新規または再利用の別を記録します。 逐次割り当てと複合的な統合をまたいで、ラウンドの区切りを維持します。

デフォルトのレビューポリシー

呼び出し元から Review Brief が提示されない場合は、行ごとに 1 件の Review Request を使用します。 モードによって、書き込み可能なスキルをレポートのみの評価に限定します。

レビュースキル	モード
code-review	標準と仕様のレビュー
simplify	再利用、簡素化、効率性、抽象度の各レビュアーによるレポートのみの複合レビュー用スキル
improve-codebase-architecture	codebase-design の用語とレポートのみの調査役を 1 名使用する、差分の範囲に限定した掘り下げ分析。HTML の作成、ブラウザーの起動、grilling loop の開始、ファイルの書き込みは行わず、調査結果を返します
ask-exemplar	組み込み評価

スコープ契約を確立する

最初のラウンドの前に、ユーザーのブリーフ、対象の Issue または PR、リポジトリの用語、リポジトリの指示、関連する永続ドキュメントから、簡潔なスコープ契約を導き出します。 意図された動作、標準的な用語、所有する依存関係またはモジュールの境界、明示的な非目標、必須の検証を記録します。

不具合の指摘では、スコープ契約の条項または具体的なリポジトリ標準を守る必要性を示し、レビュー対象の変更における影響を明記します。裏付けのない所見は、検証済みの指摘や修正作業ではなく、提案として記録します。

クリーンになるまで実行

解決済みのレビュー方針は、すべてのラウンドで優先されます。Full Review Round ではすべての Review Request をディスパッチし、Delta Review Round では Impact した Review Request のみをディスパッチします。最初のラウンドは Full です。 修正後、Impact したセットが完全であることが明確に確認でき、受理したすべての指摘が 検証済みクローズとなり、Repair Gate に合格し、修正によって公開インターフェース、 モジュール間の動作、依存関係の境界、セキュリティ境界、または契約条項が変更されない 場合に限り、クリーンな Delta ラウンドで実行を終了できます。曖昧さがある場合は、 後続の Full ラウンドが必要です。

オーケストレーション状態に、簡潔な台帳を2つ維持します。対象には記録しないでください。

• Run Ledger には、各ラウンドのスコープ、HEAD、ステータス、diff hash、Reviewer の役割とエージェントの割り当ておよびプールサイズ、レポート、対象変更の結果、 修正、チェック、CI の分類を記録します。
• Claim Ledger では、各指摘を場所と意味でキー付けし、その Scope Contract または リポジトリ標準の根拠、来歴、証拠、必要な検証、および次のいずれかの指摘状態を 記録します。accepted-pending、accepted-repaired、理由付きの rejected、 証拠の不足がある unverified、または verified-closed。提案された各修正案は、 来歴と処置（accepted、理由付きの rejected、または置き換え案を示した superseded） を個別に記録します。修正案の判断を消去せずに、重複する指摘を統合します。 記録済みの理由に新たな証拠が答える場合に限り、却下または置き換え済みの修正案を 再検討します。

修正後は、修正差分から Impact する Review Request を導き出します。受理された指摘を 報告したすべてのリクエストと、変更されたファイル、インターフェース、関連パス、 または動作を基準の対象とするすべてのリクエストを含めます。曖昧さがある場合は 対象を広げます。このセットが Review Policy の全体に相当する場合、次のラウンドは Full です。

ラウンドのバリア

1つの Review Round が所有する対象スナップショットは不変です。早く届いた Reviewer レポートは、対応を始めずにキューに入れます。必須のすべての役割からレポートが届き、 対象がラウンドに記録された HEAD、ステータス、diff hash と一致する状態が維持されて いる場合に限り、バリアを閉じます。直接のチェック、統合、検証、編集は、バリアが 閉じた後にのみ開始します。レビューが失敗またはタイムアウトした場合、あるいは対象が 変更された場合、結果は incomplete となります。部分的なラウンドでは、修正を 許可しません。

1. 対象の HEAD、ステータス、完全な差分を記録します。これによりラウンドのバリアを開きます。
2. Full または Delta のラウンドを選択し、各リクエストを含める理由を記録します。対象に含めたすべての役割を Schedule reviewers に割り当てます。すべてのレビュアーに、同じ対象、ベース、差分の範囲、Scope Contract、Claim Ledger、リポジトリの指示を渡します。台帳の結論は権威ではなく、事前の証拠として扱います。割り当てられた各レビュアーは、現在の対象を独自に調査し、異議を唱えることができます。名前付きスキルのレビュアーは、そのスキルと必須の参照資料を読み、従います。アドホックレビュアーは、Review Brief をレビュー基準として使用します。
3. 各レビュアーに、委任せず、割り当てられた役割だけを調査して報告するよう求めます。複合スキルの場合は、角度ごとのレポートを別々に保持します。オーケストレーターは、ラウンドのバリアが閉じた後に集約ルールを適用します。レビュアーはファイルを変更したり、コミットしたり、フォージにコメントしたり、プッシュしたりしてはいけません。各指摘には、場所、主張、証拠、推奨する修正を含めます。問題のないレビュアーは、その旨を報告します。
4. 続行する前に、ラウンドのバリアを閉じます。
5. ソースの調査では判断できない、観察可能な主張については、対象範囲内で最小限の直接チェックを行います。そのチェックが利用できない場合は、同じ主張を新たなものとして再割り当てせず、自動化上のギャップを 1 つ保持します。未検証のままの主張は指摘ではなく、修正の対象にもなりません。
6. 編集前に Synthesis Gate を通過します。すべてのレビュアーの出所情報を保持しながら、根本原因ごとに主張をまとめます。各仮説を、正確なソース、Scope Contract、リポジトリの標準、または観察可能な動作に照らして独自に検証し、修正案の相違を解決します。各修正案を、契約、起こり得る回帰経路、同じ機能を呼び出す箇所に照らしてテストします。推測に基づく強化や対象範囲の拡大は却下し、互換性のある最小限の根本原因修正をまとめて実施します。修正案の相違を解決できない場合、結果は incomplete となります。
7. 統合した修正一式を、範囲を絞って適用します。Verified Finding がない限り、対象の範囲を広げたり、隣接するコードを編集したりしてはいけません。
8. 結果を記録する前に、Scope Contract で必須とされる検証と、関連性の最も高い最小限のテスト、lint、型チェックを実行して Verification Gate を通過します。既存のテストで変更された出力面を確認できない場合は、その出力面を直接テストします。修正後は Repair Gate として、修正した各主張が存在しないことを独自に確認し、根本原因を共有する同種の経路を調査します。コードまたはテストの失敗、必須の検証の未達成、安全でない修正がある場合、結果は incomplete となります。 対象に未コミットの変更がなく、実行の head SHA がラウンドで記録した HEAD と一致する場合に限り、リモート CI をレビュー対象のスナップショットに対する証拠として扱います。それ以外の場合、その実行は Verification Gate の証拠ではなく、過去のコンテキストです。すでに該当する CI が存在する場合は確認しますが、待機、起動、再実行はしません。実行されたステップと注釈を調べ、成功しなかったリモート CI の結果を、コードまたはテストの失敗、インフラまたはアカウントの失敗、キャンセルまたは置き換えられた実行、証拠の入手不可のいずれかに分類します。インフラ上の理由でステップが実行されなかった場合は、最も近い安全なローカル相当の検証を実行し、リモート CI は成功ではなく利用不可と報告します。インフラのみが原因の CI は、それらのローカル相当の検証で必須の検証を満たしていれば、clean を妨げません。
9. ラウンドの Review Outcome を記録します。Verified Findings がない Full ラウンドは clean です。修正を行ったラウンドは fixed となり、Impacted Review Requests から選択したラウンドを開始します。対象が Review Policy の全体であれば Full、そうでなければ Delta です。Verified Findings がない Delta ラウンドは、上記の限定修正の終了条件を満たしていれば clean です。満たしていなければ ready-for-full-review となり、Full ラウンドを開始します。incomplete の場合は、追加編集を行わずに実行を終了します。 各 fixed ラウンドでターゲットに変更があり、Repair Gateを通過する場合に限り、続行してください。新たな証拠がないままVerified Findingが繰り返される場合、または根拠に基づく修復ができないラウンドがある場合は、ラウンドを繰り返さず、結果を incomplete とします。

結果を返す

どちらの出力形式でも、各リクエストで選択されたモードとレポート専用の事前チェック結果を含め、引き継ぎ先に受け入れた基準と境界が伝わるようにしてください。

次のいずれかの出力形式を選択してください。

• 1ラウンドで clean となった場合は、簡潔な後続処理向けの引き継ぎ情報のみを返します。ポリシーのソース、Review Requestの正確な件数、Scope Contract、ラウンドのスコープ、レビュアーの割り当てとプールの規模、ターゲットとベースの参照、最終HEADとdiffハッシュ、チェックとCIの分類、最終結果を、それぞれ1回ずつ含めてください。ワークフローを別途説明したり、空のカテゴリを含めたりしないでください。省略されたカテゴリは None として表示せず、存在しないものとして扱います。
• それ以外の場合は、ポリシーのソース、解決済みReview Request、Scope Contract、各ラウンドのスコープとレビュアーの割り当て、空でないClaim Ledgerの状態、Verified Finding、却下されたクレームとその対処、未検証のクレームと証拠の不足、置き換えられた対処、自動化の不足、修復、Verification GateとRepair Gate、チェックとCIの分類、Review Outcomeを報告します。簡潔な表またはリストを使用し、空のカテゴリは省略し、clean の出所が繰り返される場合は1回だけ記載してください。最後に、ターゲットとベースの参照、最終HEADとdiffハッシュ、最終結果、空でない修復とクレームの概要、チェックとCIの分類、自動化の不足、レビュアーの割り当てを含む、簡潔な後続処理向けの引き継ぎ情報を記載します。

修復した各ラウンドでは、Synthesis Gate、Repair Gate、および fixed の結果を明記してください。修復した各クレームについて、レビュアーの出所と完全な状態遷移を記載した台帳行を1行ずつ作成してください。事前チェックの結果が incomplete の場合は、ターゲット、リポジトリの履歴、forgeの状態に変更がないことを明記してください。各Composite Review Skillについて、必須のすべての役割、それぞれに割り当てられたエージェント、およびオーケストレーターによる統合を出所として記載してください。ピーク時のプールの規模と、レビュアーを再利用したかどうかも記録してください。Review Requestの正確な件数を記載し、各Deltaサブセットについて説明するとともに、正式なReview Policyに変更がないことを確認してください。

最終結果は、必ず1つだけ記載してください。後続処理向けの引き継ぎ情報が、この実行から後続の履歴管理スキルや公開スキルに渡す唯一の入力となります。

• clean：完全な現在のdiffを対象とするFullラウンドでVerified Findingがない場合、または後続のclean Deltaラウンドが限定的な修復の終了条件を満たす場合です。
• incomplete：要求されたポリシーを安全に完了できなかった場合です。

すべての修復はコミットしないでください。コミット、リベース、コメント、プッシュは行わないでください。リポジトリの履歴管理と公開ワークフローは呼び出し元が担当します。