GitHub PR レビュー

Pull Request のレビューコメントを重大度ベースの優先順位付け、修正の適用、スレッドへの返信で解決します。

現在の PR

!gh pr view --json number,title,state,milestone -q '"PR #\(.number): \(.title) (\(.state)) | Milestone: \(.milestone.title // "none")"' 2>/dev/null

コアワークフロー

1. コメントの取得、フィルタリング、分類

REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
PR=$(gh pr view --json number -q '.number')
LAST_PUSH=$(git log -1 --format=%cI HEAD)

# インライン レビューコメント - 返信を除外（オリジナルのみ保持）
gh api repos/$REPO/pulls/$PR/comments?per_page=100 --jq '
  [.[] | select(.in_reply_to_id == null) |
   {id, path, user: .user.login, created_at, body: .body[0:200]}]
'

# PR レベルのレビュー（本文が空でないもの）（CodeRabbit セクション、Gemini など）
gh api repos/$REPO/pulls/$PR/reviews?per_page=100 --jq '
  [.[] | select(.body | length > 0) |
   {id, user: .user.login, state, submitted_at, body: .body[0:500]}]
'

レビュー添付コメントの相互確認: CodeRabbit のレビュー本文に「Actionable comments posted: N」と記載されています。一般的な pulls/$PR/comments エンドポイントがそのレビュアーからの新しいオリジナルコメント数が N より少ない場合、一部のコメントはレビュー特定のエンドポイントでのみ利用できます。それらを取得し、コメント ID でマージします：

# $REVIEW_ID はうえのレビュー取得から、$EXPECTED は「Actionable comments posted: N」を解析して取得
gh api repos/$REPO/pulls/$PR/reviews/$REVIEW_ID/comments?per_page=100 --jq '
  [.[] | select(.in_reply_to_id == null) |
   {id, path, user: .user.login, created_at, body: .body[0:200]}]
'

続行する前に ID で重複を排除します。レビュー特定のエンドポイント経由でのみ見つかるコメントは有効なインラインコメントであり、同じ方法で扱う必要があります（同じ分類、同じ in_reply_to 返信メカニズム）。

新規対既知の判定: created_at/submitted_at を $LAST_PUSH と比較します。最後のプッシュ後に投稿されたコメントが新規です。古いコメントは、サマリーテーブルで「previous round」としてマークします。

CodeRabbit レビュー本文の解析: 初回取得は分類のために本文を切り詰めます。CodeRabbit からのレビュー（user.login が coderabbitai で始まる）の場合、別途フル本文を取得します：

gh api repos/$REPO/pulls/$PR/reviews?per_page=100 --jq '
  [.[] | select(.user.login | startswith("coderabbitai")) |
   {id, submitted_at, body}]
'

CodeRabbit は diff 外、重複、細かい指摘コメントを含む構造化された <details> ブロックを投稿します。各ブロックにはファイルパス、行範囲、重大度、およびオプションで「Prompt for AI Agents」が含まれます。完全な解析ガイドについては references/coderabbit_parsing.md を参照してください。

利用可能な場合は CodeRabbit AI プロンプトを使用: コメント（またはレビュー本文）に「Prompt for AI Agents」 <details> ブロックが含まれている場合、それを使用して問題と提案されたアプローチを理解してください。修正を提案する前に、必ず実際のコードを読んでください。レビュー本文に「Prompt for all review comments with AI agents」ブロックが含まれている場合、個別のコメントを処理する前にまずそれを読んで、全体のコンテキストを理解してください。

すべてのコメントを重大度で分類し、順序で処理: CRITICAL > HIGH > MEDIUM > LOW。

重大度	インジケーター	アクション
CRITICAL	critical.svg、_🔒 Security_、_🚨 Critical_、_🔴 Critical_、「security」、「vulnerability」	必須修正
HIGH	high-priority.svg、_⚠️ Potential issue_、_🐛 Bug_、_⚡ Performance_、_🟠 Major_、「High Severity」	推奨修正
MEDIUM	medium-priority.svg、_🛠️ Refactor suggestion_、_💡 Suggestion_、「Medium Severity」	推奨
LOW	low-priority.svg、_🧹 Nitpick_、_🔧 Optional_、_🟡 Minor_、_🔵 Trivial_、_⚪ Info_、「style」、「nit」	オプション

コメントが型ラベルと色バッジの両方を持つ場合（例: _💡 Suggestion_ | _🟠 Major_）、色バッジが決定的な重大度であり、型ベースのデフォルトをオーバーライドします。

完全な検出パターンについては references/severity_guide.md を参照してください（Gemini バッジ、CodeRabbit 絵文字、Cursor コメント、キーワードフォールバック、関連コメントの発見的手法）。

2. レビューサマリーテーブルを表示

処理前に、すべてのコメントの構造化された概要を表示します：

| # | ID         | 重大度 | ファイル:行     | 型     | ステータス | サマリー        |
|---|-----------|--------|------------------|--------|-----------|-----------------|
| 1 | 123456789 | CRITICAL | src/auth.py:45     | inline | new      | SQL インジェクションリスク |
| 2 | 987654321 | HIGH     | src/db.py:346-350  | outside| new      | 結合条件が不足 |
| 3 | 555555555 | HIGH     | src/chunk.py:188   | duplicate| previous | 古いメタデータ |
| 4 | 444444444 | LOW      | tests/test_q.py:12 | nitpick | previous | 命名規則 |

• 型: inline、outside（diff 外）、duplicate、minor、nitpick（CodeRabbit セクションから）、または review（通常の PR レベル）
• ステータス: new（最後のプッシュ後に投稿）または previous（以前のラウンド）
• 関連するコメント（同じファイル、同じ根本原因、「also applies to」範囲）をグループ化し、クラスターを記録します
• 重複排除: 同じ問題がインラインコメントと CodeRabbit レビュー本文セクション（例: 重複）の両方に表示される場合、1 つのエントリを保持し、両方のソースを記録します

10 件を超えるコメントがある場合は、レビューサマリーを Claude のメモリに保存してセッション全体で追跡することを提案します。サマリーには以下を含める必要があります: PR 番号、コメント ID、重大度、ステータス（new/addressed/deferred/won't fix）、および簡潔な説明。これは、後続のプッシュ後に新しいコメントが到着する場合に、継続性を維持するのに役立ちます。

3. 各コメントを処理

各コメントを重大度順に処理:

1. コンテキストを表示: コメント ID、重大度、ファイル:行、引用
2. AI プロンプトの確認: このコメントに CodeRabbit の「Prompt for AI Agents」が利用可能な場合、それを使用して問題と提案されたアプローチを理解します
3. 提案される修正の確認: CodeRabbit に「Proposed fix」または「Suggested fix」コードブロックが含まれている場合、それを出発点として使用します（ただし正確性を確認してください）
4. 影響を受けるコードを読み取り修正を提案（AI プロンプトまたは提案される修正がコンテキストを提供している場合でも、実際のコードを必ず読んでください）
5. 「also applies to」に対応: コメントが追加の行範囲を参照する場合、すべての位置を修正に含めます
6. ユーザーに確認してから適用
7. 修正を適用（承認された場合）
8. コメント内のすべての問題を検証（複数の問題を持つコメントは一般的です）

4. 変更をコミット

git-commit スキル形式を使用します。機能的な修正は個別のコミットを取得し、化粧的な修正はバッチ処理されます：

変更の種類	戦略
機能的（CRITICAL/HIGH）	修正ごとに個別のコミット
化粧的（MEDIUM/LOW）	単一のバッチ style: コミット

コミット本文でコメント ID を参照してください。

5. スレッドに返信

インラインコメント

重要: --input - で JSON を使用します。-f in_reply_to=... 構文は機能しません。

COMMIT=$(git rev-parse --short HEAD)
gh api repos/$REPO/pulls/$PR/comments \
  --input - <<< '{"body": "Fixed in '"$COMMIT"'. Brief explanation.", "in_reply_to": 123456789}'

インラインでないコメント（CodeRabbit レビュー本文）

レビュー本文に埋め込まれたコメント（diff 外、重複、細かい指摘）にはインラインスレッドがありません。GitHub API はレビュー本文に直接返信することをサポートしていません。特定の問題を参照する一般的な PR コメントを投稿します：

gh pr comment $PR --body "Fixed in $COMMIT. Addresses outside-diff comment on file/path.py:346-350."

返信テンプレート（絵文字なし、簡潔かつプロフェッショナル）:

状況	テンプレート
修正済み	Fixed in [hash]. [修正内容の簡潔な説明]
修正なし	Won't fix: [理由]
仕様	By design: [説明]
延期	Deferred to [issue/task]. Will address in future iteration.
了承	Acknowledged. [簡潔な注記]

6. テストを実行してプッシュ

プロジェクトのテストスイートを実行します。プッシュ前にすべてのテストが合格する必要があります。レビューループを最小限にするために、すべての修正を一緒にプッシュします。

7. レビューを送信（オプション）

すべてのコメントに対応した後、正式にレビューを送信します：

• gh pr review $PR --approve --body "..." - すべてのコメントに対応、PR は準備完了
• gh pr review $PR --request-changes --body "..." - 重大な問題が残っている
• gh pr review $PR --comment --body "..." - 進捗アップデート、決定なし

8. マイルストーンを検証

gh pr view $PR --json milestone -q '.milestone.title // "none"'

PR にマイルストーンがない場合は、オープンなマイルストーンを確認します：

REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
gh api repos/$REPO/milestones --jq '[.[] | select(.state=="open")] | .[] | "\(.number): \(.title)"'

オープンなマイルストーンが存在する場合、ユーザーに通知し、割り当てを提案します：

gh pr edit $PR --milestone "[milestone-title]"

自動的に割り当てしないでください。これはリマインダーのみです。

レビューループを避ける

ボット（Gemini、Codex など）がすべてのプッシュをレビューする場合：

1. 修正をバッチ処理: すべての修正を蓄積し、一度プッシュ
2. ドラフト PR: 修正中にドラフトに変換
3. コミットキーワード: 一部のボットは [skip ci] または [skip review] を尊重します

重要なルール

• 常にインラインコメント（pulls/$PR/comments）とレビュー本文（pulls/$PR/reviews）の両方を取得する
• 常に「Actionable comments posted: N」を見つかったオリジナルと相互確認; カウントが一致しない場合は pulls/$PR/reviews/$REVIEW_ID/comments を取得する
• 常に CodeRabbit レビュー本文をすべてのセクションタイプ（diff 外、重複、マイナー、細かい指摘）について解析する
• 常に CodeRabbit の「Prompt for AI Agents」を利用可能な場合、プライマリコンテキストとして使用する
• 常に処理前にレビューサマリーテーブルを表示する
• 常にファイルを変更する前に確認する
• 常に複数の問題を持つコメント内のすべての問題が修正されたことを検証（「also applies to」範囲を含む）
• 常にプッシュ前にテストを実行する
• 常に解決されたスレッドに標準テンプレートを使用して返信する
• 常にすべてのコメントに対応した後に正式なレビュー（gh pr review）を送信する
• 常に終了時にマイルストーンを確認し、不足している場合はリマインドする
• 常に10 件を超えるコメントがある場合は、メモリにレビューサマリーを保存することを提案する
• 決してコミットメッセージやスレッド返信で絵文字を使用しない
• 決して HIGH/CRITICAL コメントを明示的なユーザー承認なしでスキップしない
• 決してマイルストーンを自動的に割り当てない - 提案のみ
• 機能的な修正 -> 個別のコミット（修正ごとに 1 つ）
• 化粧的な修正 -> 単一の style: コミットにバッチ処理
• 重複コメント -> そのラベルより高い優先度として扱う（問題は既に前に一度フラグが立っていた）
• 関連するコメント -> 根本原因またはファイルコンテキストを共有する場合、グループ化して一緒に修正

参照

• references/severity_guide.md - 重大度検出パターン（Gemini バッジ、CodeRabbit 絵文字、Cursor コメント、キーワードフォールバック、関連コメントの発見的手法）
• references/coderabbit_parsing.md - CodeRabbit レビュー本文構造、セクション解析、「Prompt for AI Agents」使用法、重複および「also applies to」処理