github-pr-review

GitHub PR レビュー

重要度に基づく優先順位付け、修正の適用、スレッドへの返信を通じて、プルリクエストのレビューコメントに対応します。

現在の 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)

# Inline review comments - filter out replies (keep only originals)
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-level reviews with non-empty body (CodeRabbit sections, Gemini, etc.)
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 from the reviews fetch above; $EXPECTED from parsing "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 と比較してください。最後のプッシュ後に投稿されたコメントは新規です。古いコメントは概要テーブルで「前回のラウンド」として記載してください。

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 は、差分範囲外のコメント、重複コメント、細かな指摘を含む、構造化された <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_）の両方がある場合、色バッジが優先される重要度であり、種類に基づく既定の重要度より優先されます。

検出パターンの詳細（Gemini のバッジ、CodeRabbit の絵文字、Cursor のコメント、キーワードによるフォールバック、関連コメントのヒューリスティック）については、references/severity_guide.md を参照してください。

2. レビュー概要テーブルを表示する

処理を始める前に、すべてのコメントの概要を構造化して表示してください。

| # | ID         | Severity | File:Line          | Type     | Status   | Summary            |
|---|------------|----------|--------------------|----------|----------|--------------------|
| 1 | 123456789  | CRITICAL | src/auth.py:45     | inline   | new      | SQL injection risk |
| 2 | 987654321  | HIGH     | src/db.py:346-350  | outside  | new      | Missing join cond  |
| 3 | 555555555  | HIGH     | src/chunk.py:188   | duplicate| previous | Stale metadata     |
| 4 | 444444444  | LOW      | tests/test_q.py:12 | nitpick  | previous | Naming convention  |

• 種類：inline（インライン）、outside（差分範囲外）、duplicate（重複）、minor（軽微）、nitpick（細かな指摘。CodeRabbit のセクションに記載）、または review（一般的な PR レベル）
• ステータス：new（最後のプッシュ後に投稿）または previous（以前のラウンドのもの）
• 関連するコメント（同じファイル、同じ根本原因、「also applies to」の範囲）をグループ化し、クラスターを記載する
• 重複を除外する：同じ問題がインラインコメントと CodeRabbit のレビュー本文のセクション（例：重複コメント）の両方にある場合は、1 件だけ残し、両方の出典を記載する

コメントが10 件を超える場合は、セッションをまたいだ追跡のため、レビュー概要を Claude のメモリに保存することを提案してください。概要には、PR 番号、コメント ID、重要度、ステータス（新規／対応済み／保留／対応しない）、簡潔な説明を含めてください。これにより、後続のプッシュ後に新しいコメントが届いた場合も、継続して対応しやすくなります。

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. スレッドに返信する

インラインコメント

重要：JSON には --input - を使用してください。-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 のレビュー本文）

レビュー本文に埋め込まれたコメント（差分外のコメント、重複コメント、軽微な指摘）には、インラインスレッドがありません。GitHub API ではレビュー本文に直接返信できません。該当する問題を具体的に示して、一般的な PR コメントを投稿してください。

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

返信テンプレート（絵文字なし、簡潔でプロフェッショナルな表現）：

状況	テンプレート
修正済み	Fixed in [hash]. [brief description of fix]
修正しない	Won't fix: [reason]
仕様どおり	By design: [explanation]
保留	Deferred to [issue/task]. Will address in future iteration.
確認済み	Acknowledged. [brief note]

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のレビュー本文を解析し、すべてのセクション種別（差分外、重複、軽微、細かな指摘）を確認してください
• 必ず利用可能な場合は、CodeRabbitの「Prompt for AI Agents」を主要なコンテキストとして使用してください
• 必ず処理を開始する前にレビューの概要表を表示してください
• 必ずファイルを変更する前に確認してください
• 必ず複数の問題を含むコメントについて、「also applies to」の範囲も含め、すべての問題が修正されていることを確認してください
• 必ずプッシュする前にテストを実行してください
• 必ず解決済みのスレッドには、標準テンプレートを使用して返信してください
• 必ずすべてのコメントに対応した後、正式なレビュー（gh pr review）を送信してください
• 必ず最後にマイルストーンを確認し、未設定の場合はリマインドしてください
• 必ずコメントが10件を超える場合は、レビュー概要をメモリに保存するよう提案してください
• コミットメッセージやスレッドへの返信に絵文字を使用しないでください
• ユーザーの明示的な承認なしに、重大度が高または致命的なコメントをスキップしないでください
• マイルストーンを自動で割り当てないでください。提案のみにしてください
• 機能修正 -> 個別のコミットにしてください（修正ごとに1件）
• 見た目の修正 -> style:コミット1件にまとめてください
• 重複コメント -> ラベルにかかわらず優先度を高く扱ってください（すでに指摘されていた問題です）
• 関連コメント -> 根本原因またはファイルのコンテキストが共通する場合は、まとめて修正してください

参考資料

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