respond-to-code-review

コードレビューへの対応

実際のレビューコメントと現在のコードを確認して作業します。コードを変更したり返信したりする前に、指摘内容を検証してください。

対象範囲

• ユーザーがコメントの確認または要約だけを求めている場合は、コメントを収集して評価し、結果を報告します。コードの編集や返信の投稿は行いません。
• ユーザーがコメントへの対応または返信を求めている場合は、検証済みの修正を適用し、関連するチェックを実行して、許可された範囲で返信します。
• リンク、番号、現在のブランチ、またはリポジトリの状況からプルリクエストまたはマージリクエストを特定します。候補が複数残る場合に限り、確認します。
• 既存のチーム認証済みツールを使用します。GitHub CLI がなく、導入すると役立つ場合は、任意の初回セットアップガイドを読み、ユーザーに案内します。インストールを希望していると決めつけてはいけません。

ワークフロー

使用時には毎回必須： フィードバックを収集する前に、レビューのプラットフォームを特定し、その手順を読みます：GitHub、GitLab、またはBitbucket。このスキルを以前に使用したことがあっても、該当するリファレンスを読んでください。そこには、プラットフォーム固有の収集、返信、解決の手順が記載されています。他のプラットフォームのリファレンスは読み飛ばし、初回セットアップガイドはセットアップが必要な場合にのみ読みます。

1. すべてのフィードバックを収集します。 レビューの概要、インラインコメントと返信、未解決のスレッド、CI のステータスを確認します。最後のプッシュ後に新しいコメントがないか調べます。レビュー担当者やボットの種類はリポジトリによって異なります。Copilot、Codex、Claude、その他のボットが設定されていると決めつけてはいけません。
2. 指摘ごとに検証します。 該当するコードを調べ、可能であれば動作を再現するか、対象を絞ったチェックを実行します。ライブラリや API に関する指摘の場合は、最新のドキュメントを確認します。各指摘を「妥当」「対応済み」「不明確」「裏付けなし」に分類し、変更しなかった項目については根拠を説明します。
3. 依頼された場合に、対象を絞って修正します。 リポジトリのブランチ、コミット、テストのルールに従います。独立した修正は、個別にレビューできる状態に保ちます。コメントに応えるために無関係な動作を変更してはいけません。また、関連するチェックに合格するまでは、修正したと主張してはいけません。
4. レビューに返信します。 修正内容、根拠、変更しなかった項目の理由を含め、すべての指摘を網羅する返信を1つ投稿します。複数のレビュー担当者からの指摘であっても、これを標準とします。ユーザーから依頼された場合、またはプラットフォームやリポジトリでスレッドごとの返信や解決が必要な場合に限り、個別のスレッドに返信します。重複した返信は避けます。
5. 対応可能な状態か確認します。 最新のチェック結果とレビューのステータスを確認します。ユーザーがマージを許可している場合（会話中にすでに許可している場合を含む）に限り、マージします。コメントに対応しただけでは、マージの許可を得たことにはなりません。

コードとドキュメントを確認しても指摘が不明確な場合、またはレビュー担当者同士の意見やユーザーの判断が食い違う場合は、食い違いを説明し、判断に必要な情報を尋ねます。スレッドを閉じるためだけに、未検証の提案を適用してはいけません。

レビュー待ち

リポジトリの既知の設定上、依頼されている、またはレビューが期待されている担当者だけを待ちます。リアクション、レビューコメント、レビュー依頼の状態変更があった場合は、活動があったことを示すものとして、もう少し待ってから再確認します。明確な辞退があれば、待機を終了します。動きがない場合は、3〜4分間隔で最大3回確認し、その後、まだレビューがないことを報告してポーリングを終了します。利用できる場合は、タスクをブロックするのではなく、タイマーやバックグラウンド監視を使用します。コメントがなかったという理由だけで、ボットのレビューに合格したと主張してはいけません。ユーザーが任意のレビュアーを有効にしたい場合は、レビューボットのセットアップを参照します。セットアップは、既存のフィードバックへの対応とは別です。

返信形式

各指摘について、該当箇所またはレビュー担当者の参照先を示し、次のいずれかを記載してください。

• 修正済み： 変更内容、テストまたは確認による根拠、可能であればコミットを示します。
• 対応済み： 既存のコードまたは以前のコミットで対応している箇所を示します。
• 変更なし： 変更しない具体的な理由と、それを裏付けるコードまたはドキュメントを示します。
• 判断が必要： 未解決の質問と、PR または MR への影響を示します。

内容をひと目で把握できるよう、返信は簡潔にしてください。指摘に対応し、チームのワークフローで許可された後にのみ、スレッドを解決してください。