---
name: git-review-respond
description: Respond to GitHub PR review comments - analyze, fix code, and reply to each comment
argument-hint: "[PR number]"
---

# PR Review Comment Response Skill

GitHub PRのレビューコメントを取得・分析し、コード修正・コミット・返信を一括で行う。

## 処理手順

### Step 1: PR番号の特定

- `$ARGUMENTS` が数値として指定されていればそのPR番号を使用する
- `$ARGUMENTS` が空（引数なし）の場合、現在のブランチからPRを自動判定する:
  - `gh pr view --json number,state,headRefName,title,url`（現在のブランチに紐づくPRを解決）を実行する
  - PRが見つかれば、それを提示してそのPR番号を使用する:

    ```text
    現在のブランチ `<branch>` の PR #XX を対象とします。
    ```

  - PRが見つからない場合（コマンドが失敗、または現在のブランチにPRがない場合）、従来どおりユーザーにPR番号を尋ねる:

    ```text
    現在のブランチからPRを検出できませんでした。対応するPRの番号を教えてください。
    ```

- `$ARGUMENTS` が指定されているが数値でない場合、ユーザーにPR番号を尋ねる:

  ```text
  対応するPRの番号を教えてください。
  ```

- ユーザーの回答からも明確な数値を判別できない場合はエラーとして終了する。推測や曖昧な解釈は行わない:

  ```text
  エラー: PR番号を特定できませんでした。数値で指定してください。
  ```

### Step 2: PR情報取得・ブランチ切り替え

1. `gh pr view <PR番号> --json state,headRefName,number,title,url` でPR情報を取得
2. コマンドが失敗した場合（番号に対応するPRが存在しない場合）:
   - `gh issue view <PR番号>` でIssueとして存在するか確認し、Issueの場合は以下を表示して終了:

     ```text
     エラー: #XX はIssueです。PRの番号を指定してください。
     ```

   - Issueでもない場合は以下を表示して終了:

     ```text
     エラー: PR #XX は存在しません。
     ```

3. PRの `state` を確認:
   - `OPEN` 以外の場合 → 「このPRは既にクローズ/マージされています」と警告して終了
4. PRの `headRefName` ブランチにチェックアウト:
   - `git checkout <headRefName>` を実行
   - リモートの最新を `git pull` で取得

### Step 3: レビューコメント取得・フィルタリング

1. REST APIでレビューコメントを取得:

   ```bash
   gh api repos/{owner}/{repo}/pulls/<PR番号>/comments --paginate
   ```

2. GraphQL APIでレビュースレッドを取得（スレッドレベルのノードID含む）:

   ```graphql
   query {
     repository(owner: "{owner}", name: "{repo}") {
       pullRequest(number: <PR番号>) {
         reviewThreads(first: 100) {
           nodes {
             id
             isResolved
             comments(first: 100) {
               nodes {
                 databaseId
               }
             }
           }
         }
       }
     }
   }
   ```

   **注記**: スレッドレベルの `id` フィールド（GraphQL node ID）を抽出し、後でスレッド解決に使用するためのマッピング `{コメントdatabaseId → スレッドId}` を作成する。

3. 以下のコメントを除外:
   - `in_reply_to_id` が設定されているコメント（返信コメント）
   - 解決済みスレッドに属するコメント

4. 対象コメントが0件の場合 → 「対応すべきレビューコメントはありません」と表示して終了

### Step 4: 各コメントの分析・分類

対象の各コメントについて、以下の情報を確認する:

- `path`: 対象ファイルパス
- `line` / `original_line`: 対象行
- `diff_hunk`: 差分コンテキスト
- `body`: コメント本文

#### 妥当性評価の判断基準

分類の前に、各コメントの指摘内容を以下の基準で批判的に評価する:

1. **実害の有無**: 実際のバグ・セキュリティリスク・パフォーマンス問題を指摘しているか？単なるスタイル提案や好みの違いに過ぎないものは「対応不要」寄りに判断する
2. **プロジェクト整合性**: 指摘内容がプロジェクトの既存パターンやルールと整合しているか？プロジェクトの規約に反する提案は採用しない
3. **コスト対効果**: 変更による複雑性増加に見合う価値があるか？過度な防御的コーディングや不要な抽象化の提案は却下する
4. **自動レビューツールへの対応**: Copilot等の自動レビューツールからの指摘は特に批判的に評価する。自動ツールはプロジェクト固有のコンテキストを理解していないため、忖度せず不要なものは「対応不要」に分類する

これらの基準を適用した上で、各コメントを以下のいずれかに分類する:

| 分類 | 判断基準 | 対応 |
|------|----------|------|
| **要修正** | コード変更を求めている（修正依頼、改善提案、バグ指摘など） | コード修正 + 返信 |
| **要説明** | 質問、確認、意図の確認など | 返信のみ |
| **対応不要** | 称賛、感想、既に対応済みなど | 返信のみ（または返信不要） |

**注意**: `path` のファイルが存在しない場合（削除済み）、そのコメントはスキップし、その旨を記録する。

### Step 5: 分析結果の提示（ユーザー確認）

返信ドラフトは Step 9 のスタイルガイドラインに従って書くこと — そのまま投稿される。「対応不要」で返信が不要な場合は `(返信不要)` と記載する。

分類結果を以下の形式で一覧表示し、ユーザーの承認を待つ:

```text
## PRレビューコメント分析結果

PR #XX: <タイトル>
対象コメント: X件

### 要修正 (X件)
1. `path/to/file.ts:L42` - @reviewer
   > コメント内容の要約
   → 修正方針: ～を変更する
   → 返信ドラフト: 「`xxx` を `yyy` に変更しました。」

### 要説明 (X件)
1. `path/to/file.ts:L10` - @reviewer
   > コメント内容の要約
   → 回答方針: ～について説明する
   → 返信ドラフト: 「<回答内容>」

### 対応不要 (X件)
1. `path/to/file.ts:L5` - @reviewer
   > コメント内容の要約
   → 理由: 称賛コメント
   → 返信ドラフト: (返信不要)

この内容で対応を進めてよいですか？
```

**ユーザーの承認を得てから次のステップに進むこと。** ユーザーが分類や方針を変更した場合はそれに従う。

### Step 6: コード修正

承認後、「要修正」に分類されたコメントに対してコード修正を実施する。

- 対象ファイルを読み、コメントの指摘箇所を特定して修正する
- 修正はコメントの意図に沿った最小限の変更とする
- 関連する他のファイルへの影響がある場合はそれも修正する

### Step 7: 検証

プロジェクトの品質チェックコマンド（lint、test等）を実行して修正が問題ないことを確認する。

いずれかが失敗した場合は修正して再実行する。

### Step 8: コミット・プッシュ

1. 変更したファイルを個別に `git add <ファイルパス>` でステージング（`git add .` は使わない）
2. 以下の形式でコミット:

   ```text
   fix: address PR #<PR番号> review comments
   ```

   ※ Co-Authored-By を含める
3. `git push` でリモートにプッシュ

**注意**: 「要修正」コメントがなくコード変更がない場合、このステップはスキップする。

### Step 9: コメント返信とスレッド解決

Step 5 で承認された返信ドラフトをそのまま使用する。Step 6 の実際の修正内容が当初の方針から乖離した場合のみ調整する。

各コメントに対して以下を実施する:

1. **返信を投稿** - `gh api` で返信する。返信は元のコメントと同じスレッドに投稿する:

   ```bash
   gh api repos/{owner}/{repo}/pulls/<PR番号>/comments \
     -method POST \
     -f body="<返信内容>" \
     -F in_reply_to=<元コメントのID>
   ```

2. **スレッドを解決** - 返信投稿直後に、GraphQL mutation でスレッドを解決する:

   ```bash
   gh api graphql -f query='
     mutation {
       resolveReviewThread(input: {threadId: "<スレッドのnode ID>"}) {
         thread {
           isResolved
         }
       }
     }
   '
   ```

   - Step 3 で抽出したスレッドのnode ID（GraphQLクエリの `id` フィールド）を使用する
   - mutationに失敗した場合は警告をログして続行する（返信は既に投稿されているため、スレッドは手動で解決可能）

返信内容のガイドライン:

- **要修正（修正済み）**: 修正内容を簡潔に説明（例: 「修正しました。`xxx` を `yyy` に変更しています。」）
- **要説明**: 質問に対する回答を記述
- **対応不要**: 必要に応じて理由を説明、または感謝の返信

返信は日本語で記述する（レビュアーが日本語の場合）。レビューコメントが英語の場合は英語で返信する。

**スタイルガイドライン**（品質を落とさず出力トークンを節約する）:

- 挨拶や謝辞で始めない（例: 「ご指摘ありがとうございます」「Thanks for the review」）
- 締めの定型句で終わらない（例: 「よろしくお願いします」「ご確認ください」）
- 過剰な謙譲表現を避ける — 「〜させていただきました」「〜いたしました」ではなく、平叙のます形を使う
- 確信のある事実にはヘッジ（「〜と思います」「〜かと思われます」）を付けない。本当に不確かな場合のみ残す
- 情報を加えない枕詞（「念のため」「一応」「ちなみに」）は省く
- 同じ事実を言い回しを変えて繰り返さない

維持する要素: 修正の要点（何を／なぜ）、質問への直接的な回答、提案を採用しない場合の根拠、仕様判断の背景説明。

**署名**: 各返信本文の末尾に以下の署名を付与する:

```text
🤖 Generated with [Claude Code](https://claude.com/claude-code)
```

### Step 10: 完了サマリー

対応結果を以下の形式で表示する:

```text
## 完了サマリー

PR #XX: <タイトル>
<PR URL>

- 修正済み: X件
- 説明返信: X件
- 対応不要: X件
- スキップ: X件（理由: ファイル削除済みなど）
- 解決済みスレッド: X件

コミット: <コミットハッシュ>
```

**注記**: 返信が投稿されたすべてのスレッドは Step 9 の GraphQL mutation で自動的に解決される。カウントは正常に解決されたスレッド数を表す。