Github Pr Review

GitHub PR review

Resolves Pull Request review comments with severity-based prioritization, fix application, and thread replies.

Current PR

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

Core workflow

1. Fetch, filter, and classify comments

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]}]
'

Cross-check review-attached comments: CodeRabbit's review body states "Actionable comments posted: N". If the general pulls/$PR/comments endpoint returns fewer than N new originals from that reviewer, some comments are only available via the review-specific endpoint. Fetch them and merge by comment 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]}]
'

Deduplicate by id before continuing. Comments found only via the review-specific endpoint are valid inline comments and should be treated identically (same classification, same in_reply_to reply mechanism).

Filter new vs already-seen: compare created_at/submitted_at with $LAST_PUSH. Comments posted after the last push are new. Mark older comments as "previous round" in the summary table.

Parse CodeRabbit review bodies: the initial fetch truncates bodies for classification. For reviews from CodeRabbit (user.login starts with coderabbitai), fetch the full body separately:

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

CodeRabbit posts structured <details> blocks containing outside-diff, duplicate, and nitpick comments. Each block includes file path, line range, severity, and optionally a "Prompt for AI Agents" with pre-built context. See references/coderabbit_parsing.md for full parsing guide.

Use CodeRabbit AI prompts when available: if a comment (or the review body) contains a "Prompt for AI Agents" <details> block, use it to understand the issue and suggested approach. Always read the actual code before proposing a fix. If the review body contains a "Prompt for all review comments with AI agents" block, read it first for cross-comment context before processing individual comments.

Classify all comments by severity and process in order: CRITICAL > HIGH > MEDIUM > LOW.

When a comment has both a type label and a secondary color badge (e.g., _💡 Suggestion_ | _🟠 Major_), the color badge is the binding severity and overrides the type-based default.

See references/severity_guide.md for full detection patterns (Gemini badges, CodeRabbit emoji, Cursor comments, keyword fallback, related comments heuristics).

2. Show review summary table

Before processing, display a structured overview of all comments:

| # | 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  |

• Type: inline, outside (outside diff), duplicate, minor, nitpick (from CodeRabbit sections), or review (generic PR-level)
• Status: new (posted after last push) or previous (from earlier rounds)
• Group related comments (same file, same root cause, "also applies to" ranges) and note clusters
• Deduplicate: if the same issue appears both as an inline comment and in a CodeRabbit review body section (e.g., duplicate), keep one entry and note both sources

If there are more than 10 comments, suggest saving a review summary to Claude's memory for tracking across sessions. The summary should include: PR number, comment IDs, severity, status (new/addressed/deferred/won't fix), and brief description. This helps maintain continuity when new comments arrive after subsequent pushes.

3. Process each comment

For each comment, in severity order:

1. Show context: comment ID, severity, file:line, quote 2. Check for AI prompt: if CodeRabbit "Prompt for AI Agents" is available for this comment, use it to understand the issue and suggested approach 3. Check for proposed fix: if CodeRabbit includes a "Proposed fix" or "Suggested fix" code block, use it as a starting point (but verify correctness) 4. Read affected code and propose fix (always read the actual code, even when an AI prompt or proposed fix provides context) 5. Handle "also applies to": if the comment references additional line ranges, include all locations in the fix 6. Confirm with user before applying 7. Apply fix if approved 8. Verify ALL issues in the comment are addressed (multi-issue comments are common)

4. Commit changes

Use git-commit skill format. Functional fixes get separate commits, cosmetic fixes are batched:

Reference the comment ID in the commit body.

5. Reply to threads

Inline comments

Important: use --input - with JSON. The -f in_reply_to=... syntax does NOT work.

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

Non-inline comments (CodeRabbit review body)

Comments embedded in the review body (outside diff, duplicate, nitpick) do not have inline threads. The GitHub API does not support replying to a review body directly. Post a general PR comment referencing the specific issue:

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

Reply templates (no emojis, minimal and professional):

6. Run tests and push

Run the project test suite. All tests must pass before pushing. Push all fixes together to minimize review loops.

7. Submit review (optional)

After addressing all comments, formally submit a review:

• gh pr review $PR --approve --body "..." - all comments addressed, PR is ready
• gh pr review $PR --request-changes --body "..." - critical issues remain
• gh pr review $PR --comment --body "..." - progress update, no decision yet

8. Verify milestone

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

If the PR has no milestone, check for open milestones:

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

If open milestones exist, inform the user and suggest assigning:

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

Do not assign automatically. This is a reminder only.

Avoiding review loops

When bots (Gemini, Codex, etc.) review every push:

1. Batch fixes: accumulate all fixes, push once 2. Draft PR: convert to draft during fixes 3. Commit keywords: some bots respect [skip ci] or [skip review]

Important rules

• ALWAYS fetch both inline comments (pulls/$PR/comments) and review bodies (pulls/$PR/reviews)
• ALWAYS cross-check "Actionable comments posted: N" against found originals; fetch pulls/$PR/reviews/$REVIEW_ID/comments when count mismatches
• ALWAYS parse CodeRabbit review bodies for all section types (outside diff, duplicate, minor, nitpick)
• ALWAYS use CodeRabbit "Prompt for AI Agents" as primary context when available
• ALWAYS show the review summary table before processing
• ALWAYS confirm before modifying files
• ALWAYS verify ALL issues in multi-issue comments are fixed, including "also applies to" ranges
• ALWAYS run tests before pushing
• ALWAYS reply to resolved threads using standard templates
• ALWAYS submit formal review (gh pr review) after addressing all comments
• ALWAYS check milestone at the end and remind if missing
• ALWAYS suggest saving a review summary to memory when there are more than 10 comments
• NEVER use emojis in commit messages or thread replies
• NEVER skip HIGH/CRITICAL comments without explicit user approval
• NEVER assign milestone automatically - suggest only
• Functional fixes -> separate commits (one per fix)
• Cosmetic fixes -> batch into single style: commit
• Duplicate comments -> treat as higher priority than their label (issue was already flagged before)
• Related comments -> group and fix together when they share root cause or file context

References

• references/severity_guide.md - Severity detection patterns (Gemini badges, CodeRabbit emoji, Cursor comments, keyword fallback, related comments heuristics)
• references/coderabbit_parsing.md - CodeRabbit review body structure, section parsing, "Prompt for AI Agents" usage, duplicate and "also applies to" handling

CodeRabbit review parsing

Guide for extracting and processing all comment types from CodeRabbit PR reviews.

Review body structure

CodeRabbit posts a single PR-level review (via pulls/$PR/reviews API) containing multiple sections as collapsible <details> blocks. The body follows this structure:

Actionable comments posted: N

> [!CAUTION]
> Some comments are outside the diff and can't be posted inline...

<details>
<summary>⚠️ Outside diff range comments (N)</summary>
  (actionable comments on code outside the PR diff)
</details>

<details>
<summary>♻️ Duplicate comments (N)</summary>
  (issues already flagged in a previous review)
</details>

<details>
<summary>🟡 Minor comments (N)</summary>
  (lower severity comments grouped to reduce inline noise)
</details>

<details>
<summary>🧹 Nitpick comments (N)</summary>
  (style/convention issues, lowest priority)
</details>

<details>
<summary>🤖 Prompt for all review comments with AI agents</summary>
  (global prompt covering all comments in this review)
</details>

<!-- Informational sections (not actionable, ignore): -->
<details><summary>ℹ️ Review info</summary></details>
<details><summary>⚙️ Run configuration</summary></details>
<details><summary>📥 Commits</summary></details>
<details><summary>⛔ Files ignored due to path filters (N)</summary></details>
<details><summary>📒 Files selected for processing (N)</summary></details>
<details><summary>🚧 Files skipped from review as they are similar to previous changes (N)</summary></details>

Not all sections are always present. CodeRabbit only includes sections that have comments. Other severity-based sections (e.g., "🔴 Critical comments", "🟠 Major comments") may also appear.

Fetching CodeRabbit reviews

REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
PR=$(gh pr view --json number -q '.number')

# Get all CodeRabbit review bodies (may be multiple reviews across pushes)
gh api repos/$REPO/pulls/$PR/reviews?per_page=100 --jq '
  [.[] | select(.user.login | startswith("coderabbitai")) |
   {id, submitted_at, body}]
'

The id field is the review ID (visible in the GitHub URL as #pullrequestreview-<id>). Use this as the stable identifier for tracking.

Parsing sections from the body

Each section is a <details> block. Extract them by matching the summary text:

Other severity-based sections like "🔴 Critical comments" or "🟠 Major comments" may appear. Treat any unrecognized <details> section with comments as actionable and classify by per-comment severity.

Informational sections (ℹ️ Review info, ⚙️ Run configuration, 📥 Commits, ⛔ Files ignored due to path filters, 📒 Files selected for processing, 🚧 Files skipped from review as they are similar to previous changes) are not actionable. Ignore them.

Per-comment structure inside sections

Each file group is wrapped in a <details> block. The summary format varies:

<!-- Outside diff / Duplicate sections: file path + count -->
<details>
<summary>file/path.ext (N)</summary>

<!-- Minor / Nitpick sections: file path + line range + count -->
<details>
<summary>file/path.ext-X-Y (N)</summary>

Inside each file group, individual comments follow this pattern:

`X-Y`: _<emoji> <type>_ | _<color> <severity>_

**Title text**

Description paragraph(s)...

As per coding guidelines, `path/**`: "quote..."    (optional, references project rules)

Also applies to: X-Y, X-Y    (optional, other line ranges with same issue)

<details><summary>Proposed fix</summary>

code suggestion

</details>

<details><summary>Prompt for AI Agents</summary>
prompt text...
</details>

Key fields to extract:

• File path: from the <details><summary> wrapping the file group
• Line range: backtick-formatted ` X-Y at the start of each comment (may also appear in the file summary as path.ext-X-Y`)
• Severity: emoji + type label and optional color severity (see severity_guide.md)
• Title: bold text after the severity line
• "Also applies to": additional line ranges in the same file with the same issue
• Proposed fix / Suggested fix: code suggestion inside <details>. Summary text varies widely, with optional emoji prefix and description. Examples: Proposed fix, Suggested fix, 🔧 Proposed fix (...), 💡 Proposed fix, 🔒 Suggested direction, ✨ Optional: ..., ♻️ Suggested cleanup, 🔎 Suggested assertion hardening, ♻️ Suggested diff. Match any <details> block whose summary contains "fix", "suggest", "proposed", or "optional"
• Prompt for AI Agents: per-comment context prompt inside <details>

Using the "Prompt for AI Agents"

CodeRabbit provides two levels of AI prompts:

Per-comment prompt

Inside each comment's <details><summary>Prompt for AI Agents</summary> block. Contains:

• The specific file and line range
• The issue description with context
• References to coding guidelines or project conventions
• The suggested fix approach

Global prompt

At the bottom of the review body, inside <details><summary>Prompt for all review comments with AI agents</summary>. Contains:

• Aggregated context for all comments in the review
• File paths, line ranges, and descriptions for every comment
• Useful for batch processing multiple comments at once

How to use these prompts: 1. When processing a comment, check if it has a per-comment prompt 2. If present, use it to understand the issue and suggested approach 3. Always read the actual code before proposing a fix, even when the prompt provides context 4. For batch processing, use the global prompt to understand all issues at once before diving into individual fixes

Inline comments vs review body comments

CodeRabbit posts comments in two ways:

ALWAYS fetch both endpoints to get the complete picture. Inline comments may reference issues also mentioned in the review body (especially duplicates).

Review-attached comment gap

CodeRabbit's "actionable comments" are posted as part of a review object. The general pulls/$PR/comments endpoint may not surface these comments, or may surface them with a delay. When the review body states "Actionable comments posted: N" but the general endpoint returns fewer than N new originals from CodeRabbit, fetch the missing comments via the review-specific endpoint:

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]}]
'

Deduplicate by id against the general endpoint results. Comments found only via this endpoint are standard inline comments and support the same in_reply_to reply mechanism.

"Also applies to" handling

Some comments include Also applies to: 258-266, 291-296. These indicate the same issue exists at multiple locations in the same file. When fixing:

1. Fix the primary location (the one with the full description) 2. Apply the same fix pattern to all "also applies to" ranges 3. Verify each location, as the exact code may differ slightly

Duplicate comments

Comments in the "Duplicate comments" section were already flagged in a previous review. They reappear because the underlying issue was not fixed. Treat them as:

• Same severity as indicated in their label
• Higher actual priority than their label suggests (reviewer is repeating themselves)
• Check if they were previously deferred or missed

Configuration reference

CodeRabbit behavior is controlled via .coderabbit.yaml in the repo root:

reviews:
  profile: "chill"                      # chill (default) or assertive (includes nitpicks)
  enable_prompt_for_ai_agents: true     # includes "Prompt for AI Agents" in comments

• chill: lighter feedback, nitpick sections are hidden
• assertive: full feedback, includes nitpick and minor comments

Official docs: https://docs.coderabbit.ai/guides/code-review-overview

Severity guide

Reference guide for interpreting severity levels from automated review comments (Gemini, CodeRabbit, Cursor, and others).

Severity Badges

Gemini uses visual badges in review comments to indicate severity:

CRITICAL

Badge: ![critical](https://www.gstatic.com/codereviewagent/critical.svg)

Visual: Red badge with "critical" text

Meaning: Must be fixed before merge. Indicates:

• Security vulnerabilities
• Data loss risks
• Logic errors causing incorrect behavior
• Infinite loops or deadlocks
• Memory leaks or resource exhaustion

Action: Stop and fix immediately. These block merge.

---

HIGH

Badge: ![high](https://www.gstatic.com/codereviewagent/high-priority.svg)

Visual: Orange badge

Meaning: Should be fixed. Indicates:

• Performance issues
• Error handling gaps
• Potential race conditions
• Missing validation on important paths

Action: Address before merge unless there's a strong reason not to.

---

MEDIUM

Badge: ![medium](https://www.gstatic.com/codereviewagent/medium-priority.svg)

Visual: Yellow badge

Meaning: Recommended fix. Indicates:

• Code style issues
• Minor refactoring opportunities
• Unreachable code (dead code)
• Duplicate logic
• Missing edge case handling

Action: Address if time permits, or create follow-up issue.

---

LOW

Badge: ![low](https://www.gstatic.com/codereviewagent/low-priority.svg)

Visual: Blue/gray badge

Meaning: Optional improvement. Indicates:

• Import ordering
• Naming conventions
• Documentation suggestions
• Minor style preferences

Action: Optional. Can be skipped with justification.

---

Detection Patterns

Gemini Badge Detection (Primary for Gemini)

# In comment body, look for:
"critical.svg" → CRITICAL
"high-priority.svg" → HIGH
"medium-priority.svg" → MEDIUM
"low-priority.svg" → LOW

CodeRabbit Detection

CodeRabbit does not use SVG badges. It uses emoji + italic text in the comment body. The pattern is: _<emoji> <label>_ or _<emoji> <label>_ | _<color> <severity>_

CodeRabbit classifies comments along two axes: type (what kind of issue) and severity (how impactful).

Comment types (primary label)

Severity levels (secondary color badge)

When a secondary color badge is present, use it as the binding severity indicator (it overrides the type-based default above):

Note: some older reviews may use _🔵 Info_ instead of _🔵 Trivial_. Treat both as LOW.

Assertive vs chill mode

CodeRabbit has two profiles configured via .coderabbit.yaml:

• profile: chill (default) - lighter feedback, nitpicks are hidden
• profile: assertive - full feedback, includes nitpick comments

When reviewing a repo in chill mode, nitpick sections will not appear in the review body.

CodeRabbit non-inline comments (outside diff, duplicate, nitpick) are not posted as inline review comments. They are embedded in the PR-level review body (pulls/$PR/reviews) inside structured <details> blocks. Each section type has its own block with file paths, line ranges, severity, and optional AI prompts.

See coderabbit_parsing.md for the full body structure and parsing guide.

Duplicate comments from CodeRabbit indicate an issue was already flagged in a previous review and not fixed. Treat these as higher actual priority than their severity label suggests.

Cursor Comments

<!-- **High Severity** --> → HIGH
<!-- **Medium Severity** --> → MEDIUM

Keyword Detection (Fallback)

When badges or HTML comments aren't present, infer from keywords:

---

Related Comments Detection

Comments are often related when:

1. Consequence relationship: Comment B is a consequence of fixing Comment A

• Keywords: "consequence", "result of", "as mentioned above"

2. Same root cause: Multiple comments about the same underlying issue

• Keywords: "root cause", "same issue", "related to"

3. Unreachable code: After an exception handling fix, related except blocks may become unreachable

• Pattern: CRITICAL exception handling → MEDIUM unreachable code

4. Same function/method: Comments within ~100 lines in the same file, where one is CRITICAL and others are MEDIUM/LOW

---

Example: Exception Handling Pattern

Common scenario from Gemini reviews:

Comment 1 (CRITICAL): Exception handling in method_x() needs refactoring:

• FileNotFoundError should fail-fast, not retry
• Generic exceptions need sleep to avoid busy-loop

Comment 2 (MEDIUM): except FileNotFoundError block at line 186 is unreachable → This is a CONSEQUENCE of fixing Comment 1

Comment 3 (MEDIUM): except FileNotFoundError block at line 473 is unreachable → Also a CONSEQUENCE of fixing Comment 1

Resolution: Fix Comment 1 first. Comments 2 and 3 will be automatically resolved.

---

Gemini Config Reference

Gemini behavior is controlled by .gemini/config.yaml:

code_review:
  threshold: LOW          # Minimum severity to report
  auto_fix: false         # Whether to suggest auto-fixes
  blocking: false         # Whether reviews block merge

When threshold: LOW, all severities are reported. When blocking: false, reviews are advisory only.

---

Workflow Integration

1. Fetch comments: Parse severity from badge URLs in comment body 2. Sort by severity: CRITICAL → HIGH → MEDIUM → LOW 3. Group related: Use heuristics above 4. Process CRITICAL first: These often resolve MEDIUM/LOW comments 5. Skip LOW if needed: They're optional by definition

---

References

• Gemini Code Assist Documentation
• GitHub PR Review API