address-pr-comments

現在のブランチの PR から未解決のレビューコメントと一般的な会話コメントを取得し、各課題と修正案を開発者に説明します。開発者が提案について議論し、修正できるようにしたうえで、連携する開発者チームを起動して修正を実装します。コミット後、各コメントへの対応内容を GitHub で返信します。

使用方法：

• /address-pr-comments — 現在のブランチの未解決の PR コメントを取得して対応します

手順：

1. 前提条件を確認します：

   • Bash ツールで gh auth status を実行し、GitHub CLI がインストールされ、認証済みであることを確認します
   • gh が利用できない、または認証されていない場合は、以下を表示して停止します：

     GitHub CLI (gh) is not installed or not authenticated.
     Please install gh and run `gh auth login` before using /address-pr-comments.
     

2. 現在のブランチの PR を特定します：

   • git branch --show-current を実行して、現在のブランチ名を取得します
   • gh pr view --json number,title,url,state,baseRefName,author を実行して、現在のブランチに関連付けられた PR を特定し、手順 3b のために PR 作成者のログイン名（author.login）を記録します
   • PR が存在しない場合は、以下を表示して停止します：

     No pull request found for branch "<current-branch>".
     Please create a PR first, then run /address-pr-comments.
     

   • PR がクローズ済みまたはマージ済みの場合は、開発者に次の警告を表示します：

     PR #<number> is <state>. Comments may no longer be actionable.
     

     AskUserQuestion を使用して、それでも続行するかどうかを尋ねます。

3. すべての PR コメントを取得します（レビューコメントと一般コメント）：

   a) 未解決のレビューコメントを取得します：

   • GitHub GraphQL API を使用して、すべてのレビュースレッドと解決状況を取得します：

     gh api graphql -f query='
       query($owner: String!, $repo: String!, $pr: Int!) {
         repository(owner: $owner, name: $repo) {
           pullRequest(number: $pr) {
             reviewThreads(first: 100) {
               nodes {
                 id
                 isResolved
                 comments(first: 20) {
                   nodes {
                     id
                     databaseId
                     body
                     path
                     line
                     author { login }
                     createdAt
                     url
                   }
                 }
               }
             }
           }
         }
       }
     ' -f owner='{owner}' -f repo='{repo}' -F pr={pr_number}
     

   • 未解決のスレッドのみを収集します。それぞれについて、以下を記録します：
     • スレッド ID（後で返信するため）
     • ファイルパスと行番号
     • コメントスレッド全体（元のコメントとすべての返信）
     • 作成者
     • スレッド内の最初のコメントの URL（返信でリンクするため）
   • 各スレッド内で、本文が [Agent response] で終わる返信は無視します。これらは以前のエージェントの返信であり、対応すべきレビュアーのコメントではありません。ただし、スレッドが未解決のままであれば、スレッド自体には引き続き対応する必要があります。 b）レビュー本文コメント（グローバルレビューコメント）を取得する：
   • レビュアーがレビュー（Approve、Request Changes、またはComment）を送信する際、特定の行に紐づかないトップレベルの本文コメントを含めることができます。これらは「グローバル」レビューコメントです。
   • GraphQL API を使用して、すべてのレビューを取得します：

     gh api graphql -f query='
       query($owner: String!, $repo: String!, $pr: Int!) {
         repository(owner: $owner, name: $repo) {
           pullRequest(number: $pr) {
             reviews(first: 100) {
               nodes {
                 id
                 databaseId
                 body
                 state
                 author { login }
                 createdAt
                 url
               }
             }
           }
         }
       }
     ' -f owner='{owner}' -f repo='{repo}' -F pr={pr_number}
     

   • フィルター： 次の条件を満たすレビューのみを含めます。
     • body が空でない（本文がないレビューには対応すべき内容がありません）
     • body が [Agent response] で終わっていない（以前のエージェントの応答）
     • state が CHANGES_REQUESTED または COMMENTED である（「Looks great!」「LGTM」など、純粋に称賛を述べる本文がある APPROVED レビューは除外します。APPROVED レビューの本文に対応可能な具体的内容が含まれている場合は、含めてください）
     • 投稿者がボットではない
   • 残った各レビュー本文コメントについて、次の情報を記録します。
     • レビュー ID（後で返信するための databaseId）
     • レビューの状態（CHANGES_REQUESTED、COMMENTED、APPROVED）
     • 投稿者
     • コメント本文
     • 作成日
     • レビューの url（返信にリンクするため）
   • 注： これらのコメントにはファイルや行への参照はありません。PR 全体に対するトップレベルのフィードバックです。

   c）一般的な会話コメントを取得する：

   • REST API を使用して、一般的な PR コメント（イシューコメント）を取得します。

     gh api repos/{owner}/{repo}/issues/{pr_number}/comments --paginate
     

   • 対応すべきでないコメントは除外します。
     • ボットによるコメント（投稿者の type が "Bot"、またはログイン名が [bot] で終わる）
     • 本文が [Agent response] で終わるコメント（以前のエージェントの応答であり、新たに対応すべきコメントではありません）
     • 承認や確認のみを述べるコメント（例：「LGTM」「Looks good」「:+1:」）
   • PR 作成者のコメント： デフォルトでは、PR 作成者を除外しないでください。作成者は、共同作業者や自動化に向けた対応可能な会話メモ（例：CI の再実行、ビジュアルスナップショットの再生成、「X をレビューしてください」）を残すことがよくあります。これらは含めてください。
   • 作成者のノイズを任意でスキップ： コメントの user.login がステップ 2 の PR 作成者の author.login と一致し、かつ本文が明らかに対応不要な場合はスキップします。たとえば、コミット URL のみ、「Done」「Fixed」「Pushed」だけで追加の依頼がない場合、または空欄や絵文字のみの場合です。
   • 残った各一般コメントについて、次の情報を記録します。
     • コメント ID（後で返信するための id フィールド）
     • 投稿者
     • コメント本文
     • 作成日
     • コメントの html_url（返信にリンクするため）
   • 注： 一般コメントにはファイルや行への参照がなく、解決状態もありません。上記のフィルターを通過したコメントはすべて含めてください。

   d）統合して確認する：

   • 3 つのリストを統合し、作成日時の古い順に並べた 1 つのリストにします。
   • 各項目にソースとして、review（ステップ 3a）、review-body（ステップ 3b）、または general（ステップ 3c）のいずれかを付けます。
   • いずれのソースからもコメントがない場合は、次の内容を表示して終了します。

     No unresolved review comments or actionable general comments on PR #<number>. Nothing to address!
     

4. 各コメントを分析し、修正案を提示する：

   各コメント（レビューまたは一般コメント）について、問題を明確に説明し、対応案を提示してください。

   レビューコメント（コードに紐づくもの）には、次の形式を使用します。

   ## Comment <N>/<total> — [Review] `<file>:<line>` — @<author>
   
   ### Reviewer said:
   > <full comment body>
   
   ### Context:
   <Read the referenced file and surrounding code. Explain the relevant code context
   so the developer understands the issue without having to look it up.>
   
   ### Analysis:
   <Explain what the reviewer is asking for and why. Categorize as one of:>
   - **Code change** — specific modifications needed
   - **Question** — reviewer asks for clarification; may not need a code change
   - **Suggestion** — an optional improvement worth considering
   - **Concern** — a potential issue that needs investigation
   
   ### Proposed fix:
   <Describe the concrete approach to address this comment. If it's a code change,
   describe exactly what will change and where. If it's a question, draft the reply.
   If no fix is needed, explain why.>
   

   レビュー本文コメント（特定の行に紐づかない、グローバルなレビューのフィードバック）には、次の形式を使用します。

   ## Comment <N>/<total> — [Review Body] <state> — @<author>
   
   ### Reviewer said:
   > <full review body>
   
   ### Context:
   <Identify what the reviewer is commenting on. Review body comments often address the PR
   as a whole — architecture, approach, missing considerations, or cross-cutting concerns.
   Read the PR diff and relevant files to understand the context.>
   
   ### Analysis:
   <Explain what the reviewer is asking for and why. Categorize as one of:>
   - **Code change** — specific modifications needed
   - **Question** — reviewer asks for clarification; may not need a code change
   - **Suggestion** — an optional improvement worth considering
   - **Concern** — a potential issue that needs investigation
   - **Discussion** — a broader topic about approach or architecture
   
   ### Proposed fix:
   <Describe the concrete approach to address this comment. If it requires code changes,
   identify the files and describe exactly what will change. If it's a question or discussion,
   draft the reply. If no action is needed, explain why.>
   

   一般的なコメント（PR の会話）には、次の形式を使用します。

   ## Comment <N>/<total> — [General] — @<author>
   
   ### Comment:
   > <full comment body>
   
   ### Context:
   <Identify any files, functions, or areas of the codebase the comment refers to.
   If the comment mentions specific code, read the relevant files. If the comment is
   about the PR overall (architecture, approach, etc.), summarize the relevant changes.>
   
   ### Analysis:
   <Explain what the reviewer is asking for and why. Categorize as one of:>
   - **Code change** — specific modifications needed
   - **Question** — reviewer asks for clarification; may not need a code change
   - **Suggestion** — an optional improvement worth considering
   - **Concern** — a potential issue that needs investigation
   - **Discussion** — a broader topic about approach or architecture
   
   ### Proposed fix:
   <Describe the concrete approach to address this comment. If it requires code changes,
   identify the files and describe exactly what will change. If it's a question or discussion,
   draft the reply. If no action is needed, explain why.>
   

   すでに対応済み、または無効と思われるコメントの場合：

   • コメントで指摘された問題が現在のコードですでに修正されている場合は、対応済みに分類し、それを解決している既存のコードを示します
   • コメントが無効な場合（古いコードを参照している、実装を誤解しているなど）は、無効に分類し、その理由を説明します
   • これらのコメントにも GitHub での返信（ステップ 10）が必要です。返信ではコメントを認識したうえで、これ以上の対応が不要な理由を説明します

   すべてのコメントを提示した後、AskUserQuestion を使用して次のように尋ねます。

   提案する修正とともに、未解決のコメントをすべて（件）提示しました。次のことができます。

   • 特定のコメントについて質問する（例：「コメント 3 について詳しく教えて」）
   • 提案された修正の変更を依頼する（例：「コメント 2 は、Y ではなく X にしてください」）
   • すべて承認して実装に進む

   どうしますか？

5. 対話形式での検討：

   開発者は次のことができます。

   • コメントや提案された修正について確認の質問をする
   • 提案されたアプローチの変更を依頼する
   • 修正に反対し、代替案を提案する
   • コメントにはコード修正ではなく返信だけでよいと判断する

   開発者が「進めて」「承認します」「よさそうです」「実装して」など、計画を明示的に承認するまで話し合いを続けます。

   各コメントについて、最終的に承認された対応を記録しておきます。

   • コメント #N： <承認された修正の説明> または <返信のみ — コード変更なし>

6. 開発者チームを作成する：

   開発者が承認したら、修正を実装するための連携チームを編成します。

   a) チームを作成する：

   • 名前を pr-comments-<pr-number>（例：pr-comments-142）として TeamCreate を使用します

   b) 共有タスクリストを作成する：

   • コード変更が必要なコメントごとに 1 つ、さらに調整タスクを 1 つ作成するため、TaskCreate を使用します。
     • コード変更ごとに「コメント #N の修正：<短い説明>」
     • 進捗管理タスクとして「調整：修正間に競合がないことを確認」

   c) チームの規模を決定する：

   • コード変更が必要なコメントの数を数えます
   • 件数に応じて開発者を2～4 人起動します。
     • 1～3 件 → 開発者 2 人
     • 4～6 件 → 開発者 3 人
     • 7 件以上 → 開発者 4 人

   d) 作業を開発者に割り当てる：

   • 競合を避けるため、同じファイル、または密接に関連するファイルに触れるコメントは、同じ開発者に割り当てます
   • 各開発者の作業量がほぼ均等になるようにします
   • どの開発者がどのコメントを担当するか、割り当てを明確に記録します e） Task ツール（subagent_type: general-purpose）を使い、run_in_background: true を指定して開発者を起動します。
   • 各開発者にチーム名を伝え、互いに連絡を取れるようにします
   • 各開発者へのプロンプトには、次の内容を含める必要があります。
     • エージェント間の連絡に使うチーム名
     • 担当するコメントと、承認済みの修正内容の全文
     • 関連するファイルパスと現在のコードコンテキスト
     • 連携に関する指示：

       あなたはチーム <team-name> の開発者 です。コメント の修正を担当します。 同じチームの他の開発者は、別のコメントを並行して作業しています。

       変更を加える前に：

       • 編集する予定のファイルの最新版を読み込んでください（別の開発者がすでに変更している可能性があります）
       • SendMessage でチームのメッセージを確認し、他の開発者からの連携に関するメモを確認してください

       変更を加えた後に：

       • 変更したファイルと行範囲を正確にチームへ伝えてください
       • 形式：「Developer completed: edited lines - for comment #」
       • 自分の変更が他の開発者の担当内容と重複したり、影響したりする場合は、ただちに警告を送ってください

       コミットしないでください。 コードの変更のみを行ってください。コミットはチームリードが担当します。 完了したら、TaskUpdate でタスクを完了済みにしてください。

7. 進捗を監視し、連携します。

   • すべての開発者が作業を完了するまで待ちます
   • 全員の作業が完了したら、統合された変更をレビューします。
     • git diff を実行して、すべての変更を確認します
     • 競合がないか確認します。2 人の開発者が同じ行を編集していないか、矛盾する変更を加えていないか確認します
     • 競合が見つかった場合は解決します（解決方法が曖昧な場合は、開発者に確認します）
   • 最終確認として、変更した各ファイルを読み、内容に一貫性があることを確認します

8. 変更内容を提示し、確認を待ちます。

   統合した変更を開発者に提示します。

   ## Fixes Implemented
   
   ### Comment #1 — `<file>:<line>` — @<author>
   **Fix:** <description of what was changed>
   **Files modified:** `<file>` (lines <start>-<end>)
   
   ### Comment #2 — `<file>:<line>` — @<author>
   **Fix:** <description> (or "Reply only — no code change")
   
   ...
   
   ### Files Modified
   - `path/to/file.ts`
   - `path/to/other.ts`
   

   続けて、次のように表示します。

   すべての修正を実装しました。変更内容を確認し、コミットの準備ができたらお知らせください。 コミットする前に、修正内容の調整を依頼することもできます。

   コミットする前に、開発者が明示的に確認するのを待ってください。 自動でコミットしてはいけません。

9. 変更をコミットします。

   開発者が確認したら、次の手順を実行します。

   • 修正の一環として変更したファイルのみをステージングします（git add -A ではなく、git add <file1> <file2> ... を使用します）
   • リポジトリで既に使われているスタイルに沿ったメッセージでコミットを作成します。推奨形式：

     Address PR #<number> review comments
     
     - <Comment #1 short description>
     - <Comment #2 short description>
     - ...
     
     Co-Authored-By: Claude Opus 4.6 <[email protected]>
     

10. GitHub のコメントに返信します。

    コミット後、gh CLI を使って GitHub 上の各コメントに返信します。

    a）レビューコメントの場合 — コードを修正した場合：

    • 対応内容を説明して、レビューコメントのスレッドに返信します
    • 短い場合（約 20 行未満）は、修正したコードをフェンス付きコードブロックで含めます
    • 修正が長い場合は、ファイルパスと行番号を示します。

      <file>（～ 行目）で修正しました。<変更内容の簡潔な説明>

    • gh api コマンドを使って返信します。

      gh api repos/{owner}/{repo}/pulls/{pr_number}/comments -f body='<reply>' -f in_reply_to=<comment_id>
      

    b）レビューコメントの場合 — コードを修正しなかった場合（質問または返信のみ）：

    • コード変更が不要だった理由を説明する、承認済みの返信を投稿します
    • 既存のコード、設計上の決定、または懸念に対応するドキュメントを具体的に参照します c) レビュー本文のコメントの場合 — レビューに返信します：
    • REST API を使用して、レビューにコメントを投稿します：

      gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews/{review_id}/comments -f body='<reply>'
      

    • レビュアーの全体的なフィードバックに対応する形式で返信します：

      レビューについて：

    • コードを修正した場合は、インラインのレビューコメントへの返信と同じ詳細（ファイルパス、行番号、短いコードブロックなど）を含めます。

    d) 一般的なコメントの場合 — PR の会話に返信します：

    • 元のコメントに返信する形で、新しいイシューコメントを投稿します。文脈が分かるよう、元のコメントを引用します：

      gh api repos/{owner}/{repo}/issues/{pr_number}/comments -f body='<reply>'
      

    • 元の投稿者とコメントに言及する形式で返信します：

      @ さんのコメントについて：

    • コードを修正した場合は、レビューコメントへの返信と同じ詳細（ファイルパス、行番号、短いコードブロックなど）を含めます。

    e) 返信の形式（すべてのコメントタイプ）：

    • プロフェッショナルで簡潔な返信にします。
    • 簡単な要約から始めます（例：「修正しました — ...」「ご指摘ありがとうございます — ...」「変更は不要です — ...」）。
    • 関連する場合は、行番号を含むコードへの参照を記載します。
    • 各返信の末尾には、必ず新しい行に [Agent response] を追加します。 このタグは自動返信を識別し、後続の実行で対応済みのコメントをスキップできるようにします。
    • すでに対応済みのコメントには、該当するコードやコミットを示し、問題がすでに解決されていることを説明します。
    • 無効なコメントには、そのコメントが該当しない理由を丁寧に説明します。

11. クリーンアップと報告：

    • 開発チームをシャットダウンします：
      • SendMessage を通じて、各チームメイトに shutdown_request を送信します。
      • 全員から確認を受けたら、TeamDelete を呼び出します。
    • 最終的な概要を提示します：

      ## 対応した PR コメント
      
      **PR:** #<number> — <title>
      **対応したコメント:** <N>
      **コミット:** <short SHA>
      
      ### 修正内容
      - コメント #1（`<file>:<line>`）— <brief description> — GitHub で返信済み
      - コメント #2（`<file>:<line>`）— <brief description> — GitHub で返信済み
      ...
      
      ### 次のステップ
      - コミットをプッシュします：`git push`
      - CI が成功することを確認します。
      - 必要に応じて再レビューを依頼します。
      

12. エッジケースへの対応：

    • コメントが現存しないファイルを参照している場合は、分析でその旨を記し、ファイルが削除されたこと（理由を git の履歴から特定できる場合はその理由も）をレビュアーに説明する返信を提案します。
    • レビュー以降にコメントが参照する行が変更されている場合は、現在のファイルを読み、現行のコードに合わせて修正します。
    • 2 つのコメントが互いに矛盾する場合は、ステップ 4 でその矛盾を指摘し、開発者の判断を仰ぎます。
    • コメントが曖昧または不明瞭な場合は、最善と思われる解釈を提示し、ステップ 5 で開発者に確認を求めます。
    • 開発者が提案された修正をすべて却下した場合は、実装をスキップし、必要に応じて判断の理由を説明する返信を投稿します。
    • 開発エージェントが失敗した場合や、不適切な変更を行った場合は、自分で修正を試みるか、開発者に指示を仰ぎます。
    • 一般的なコメントが曖昧で、コードを明確に参照していない場合（例：「アプローチについて相談できますか？」）は、ディスカッションに分類し、PR の変更内容に基づいて懸念に対応する返信を提案します。
    • 一般的なコメントがスレッド内の別のコメントですでに回答されている場合は、そのコメントをスキップし、対応済みであることを記録します。
    • PR 作成者のコメントがワークフローのみを対象としている場合（例：スナップショットの更新、ビジュアルテストの再実行、CI の実行）は、リポジトリに応じて コード変更 または 提案 として扱います。package.json や CI 設定を確認したうえで、正確なコマンドまたはテスト対象（例：Playwright の --update-snapshots、Percy など）を提案します。