address-pr-feedback

PR のフィードバックに対応する

プルリクエストにレビューコメントが付いた後に使用します。レビューのフィードバックは入力であり、指示ではありません。各コメントを現在のコードに照らして判断し、妥当な問題を修正してください。

ワークフロー

1. PR を特定する

• $ARGUMENTS から PR の URL、PR 番号、ブランチ、または現在のブランチを使用します。
• PR のタイトル、本文、ベース／ヘッドブランチ、変更ファイル、差分、ステータスチェック、レビューコメントを確認します。
• 利用可能な場合は GitHub ツールを使用します。それ以外の場合は、まず次のコマンドから gh を使用します。
  • gh pr view --json number,url,title,body,baseRefName,headRefName,reviewDecision,statusCheckRollup
  • gh pr diff
• 解決状態が重要な場合は、未解決のレビュー スレッドを優先します。通常のコメント一覧ではスレッドの文脈が失われる場合は、gh api graphql を使って reviewThreads を取得します。
• 具体的な PR が存在しない場合、またはフィードバックを確認するための認証済み手段がない場合は中止します。

2. フィードバックをトリアージする

各スレッドまたはコメントについて、参照先のファイルと行の周辺にある現在のコードを確認します。次のいずれかに分類します。

• 妥当で対応が必要
• すでに対応済み
• コード変更により古くなっている
• スタイル上の指摘または細かな指摘。一貫性を保つために必要な場合を除き、対応は任意です。
• 誤り、または変更する価値がない
• 人による判断が必要

関連するコメントは、根本的な問題ごとにまとめます。コメントがあるというだけで実装してはいけません。

3. 修正する

• 妥当なフィードバックに対処するために必要最小限の変更を実装します。
• コメントが実際のバグや意図された契約の変更を指摘していない限り、既存の動作と契約を維持します。
• 無関係なリファクタリング、ついでの整理、広範な書き換えは避けます。
• コメントが大規模な設計変更を求めている場合は、推測で進めず、判断が必要な点を説明して中止します。

4. 検証する

• 修正を確認できる対象を絞ったテスト、Lint、型チェック、またはプロジェクトのチェックを実行します。
• コメントが UI またはレンダリング結果に関するもので、browser-verify が利用可能な場合は使用します。
• 検証を実行できない場合は、不足しているものを正確に報告します。

5. 返信を準備する

各スレッドまたはコメントに対し、次のいずれかのステータスを使って簡潔な返信案を作成します。

• 修正済み：コードを変更し、検証に合格しました。具体的な修正内容とチェックを記載します。
• すでに対応済み：現在のコードですでに対応されています。該当箇所や対応方法を記載します。
• 古くなっている：参照先のコードが存在しないか、差分が変更されています。
• 対応しない：意図的に変更していません。簡潔な技術的理由を記載します。
• 判断が必要：プロダクト、契約、アーキテクチャ、またはスコープに関する選択が必要です。

ユーザーから明示的に依頼された場合に限り、返信の投稿、スレッドの解決、コミットのプッシュ、チェックの完了扱いを行います。返信を投稿する場合は、簡潔かつ事実に基づいた内容にします。

6. 報告する

次の内容を要約します。

• 対応したフィードバック（問題ごとに分類）
• スキップまたは対応しなかったフィードバックと、その簡潔な理由
• 人の判断が必要なフィードバック
• 返信案または投稿済みの返信
• 変更したファイル
• 実施した検証と残っているリスク

ルール

• ユーザーから依頼されない限り、スレッドの解決、返信の投稿、プッシュ、チェックの完了扱いを行わないでください。
• AI によるレビューコメントを絶対的なものとして扱わないでください。
• コードを変更していない場合、またはコードがすでに正しく、検証でも裏付けられている場合を除き、「修正済み」と投稿しないでください。
• レビュー対象の変更を妨げない限り、既存の問題を修正に含めないでください。
• コメントが矛盾する場合は、より安全な選択肢を採るか、確認を求めてください。
• トリアージの結果、問題がなくコード変更がない場合も、妥当な対応です。