address-review

トリアージは振り分けの工程です。各指摘には、対応に着手する前に処置方針を割り当てます。

1. レビューを取得する

レビューは、人または別のエージェントから届く指摘の集まりです。ファイル、PR（またはPRコメント）、あるいはセッションのコンテキストとして届きます。指摘が含まれている最初の情報源から取得してください。ユーザーが示したもの、このセッションですでに受け取ったレビュー、現在のブランチのオープンなPRの順に確認し、どれにもなければユーザーに尋ねてください。

すべての指摘をリストにまとめます。情報源にあるすべての指摘がリストに含まれたら完了です。

2. すべての指摘をトリアージする

各指摘について、その主張と、すでに把握している情報に基づいて判断します。

各指摘を1行で要約し、該当する処置方針を選択肢として提示します（AskUserQuestion — 1つの質問につき1件の指摘とし、1回の呼び出しで最大4件までまとめます）。該当する処置方針を選び、推奨するものを最初に提示してください。

• fix — 妥当であり、修正すべきです。レビューで修正案が示されている場合、または修正方法が明らかな場合は、その修正内容を示してください。複数の修正案が考えられる場合は、選択するための追加質問をしてください。
• won't fix — 妥当ではない、または対応しません。
• explain (暫定) — ユーザーが内容の説明を求めています。コードを読み、説明します。
• investigate (暫定) — コードを読んで、指摘が妥当かどうかを確認します。
• defer — 妥当ですが、別の作業（別のタスクまたはイシュー）として対応します。

指摘の判断にコードを読むこと自体も、ここで選ぶ処置方針の1つです。これは暫定的な方針であり、ステップ3で実施します。

すべての指摘に処置方針が割り当てられたら完了です。

3. すべての指摘に対応する

2つの作業を並行して進めます。

• フォアグラウンド — 暫定的な処置方針では結論ではなく理解を得るため、解決に向けて対応します。コードを調査し（指摘ごとにサブエージェントを割り当て）、調査結果を報告したうえで、ユーザーと各指摘を再トリアージし（ステップ2と同様に）、最終的な処置方針であるfix、won't fix、またはdeferを決定します。
• バックグラウンド — 保留中の暫定的な指摘すべてに依存しない最終確定済みの指摘に対応します。修正を実施するか（別々のコードに触れる修正には、指摘ごとにサブエージェントを割り当てます）、先送りするイシューを作成します。再トリアージによって新たに最終確定した指摘にも対応します。

すべての修正が完了し、すべての先送り案件のイシューが作成されたら完了です。

4. 最後まで対応する

変更をコミットします。指摘ごとに1行で、処置方針と実施した内容をまとめます。レビューがPRからのものなら、ブランチをプッシュし、まとめをコメントとして投稿して、レビューを解決済みにします。それ以外の場合は、まとめをユーザーに報告します。

最後に、追加レビューが必要かどうかを提案します。まとめを伝え、PRの場合はすべてのスレッドが解決済みになったら完了です。