Fix CodeRabbit Review Comments

This skill automatically addresses CodeRabbit review comments by fetching inline comments, classifying their severity, verifying each finding against the current code, applying targeted fixes, and pushing the result.

Usage

/fix-review # Auto-fix actionable CodeRabbit comments /fix-review --dry-run # Show what would be fixed without applying /fix-review --all # Also attempt to fix suggestions and nitpicks (not just bugs/style)

Workflow

Step 1: Fetch PR and Review Data

Get the current PR details:

gh pr view --json number,url,headRefName

If no PR exists, report "No PR found for the current branch." and stop.

Get the repo identifier:

gh repo view --json nameWithOwner -q '.nameWithOwner'

Step 2: Fetch CodeRabbit Reviews and Comments

Fetch all reviews from CodeRabbit:

gh api "repos/<owner>/<repo>/pulls/<pr_number>/reviews"
--jq '[.[] | select(.user.login == "coderabbitai[bot]")]'

Fetch inline comments (including outside-diff and nitpick comments):

gh api "repos/<owner>/<repo>/pulls/<pr_number>/comments"
--jq '[.[] | select(.user.login == "coderabbitai[bot]") | {id, path, line, original_line, diff_hunk, body, created_at, subject_type}]'

Also fetch PR-level review body comments (CodeRabbit often posts a summary review with actionable items in the review body itself):

gh api "repos/<owner>/<repo>/pulls/<pr_number>/reviews"
--jq '[.[] | select(.user.login == "coderabbitai[bot]" and .body != "") | {id, body, state}]'

If no CodeRabbit reviews or comments exist, report "No CodeRabbit review comments found on this PR." and stop.

Step 3: Parse Comment Sections

CodeRabbit structures its review body into distinct sections. Parse each section:

• Inline comments (In
  @file: blocks): These reference specific files and line ranges

• Outside diff comments: Comments about code not in the current diff but affected by changes

• Nitpick comments: Low-priority style/improvement suggestions

• Duplicate comments: Comments that repeat across review rounds (may already be fixed)

For each comment, extract:

• File path (from @file reference or inline comment path)

• Line range (approximate — verify against current code)

• Referenced symbols (function names, class names, CSS selectors mentioned)

• The specific ask (what change is requested)

Step 4: Verify Each Finding Against Current Code

CRITICAL STEP — Do not skip this. For each comment:

• Read the referenced file at the specified path

• Locate the exact code referenced by the comment using:

• Line numbers (may have shifted — use symbol names as anchors)

• Function/class/variable names mentioned in the comment

• Code snippets quoted in the comment body

• Confirm the issue still exists in the current code:

• If the code has already been fixed (e.g., by a previous commit), mark as "already resolved" and skip

• If the referenced code no longer exists (refactored away), mark as "no longer applicable" and skip

• If the issue exists as described, proceed to classification

• Check for consistency with implementation — when a comment says "option X should be Y", verify by reading the actual argparse/CLI definition, not just the referenced doc line. Cross-reference:

• CLI option names: check synapse/cli.py argparse definitions

• Function signatures: check the actual function definition

• API endpoints: check the server route definitions

• CSS classes: check both .css and .js files that reference them

Step 5: Classify Comments

For each verified comment, classify into categories:

Priority rule: If a comment contains a ```suggestion code block, it is always auto-fixable regardless of category — apply the suggestion directly. Classification then only affects reporting priority.

Bug/Security (auto-fix):

• CodeRabbit header markers: ⚠️ Potential issue , 🐛 Bug , 🔒 Security

• Keywords in body (case-insensitive): bug , error , security , vulnerability , incorrect , wrong , crash , leak , null , undefined , race condition , injection , xss , overflow , missing check , unhandled , exception , type error , not defined

• Pattern: comment describes what is broken, not what could be improved

• Edge case: if body contains both a bug keyword AND consider /might want to , classify as Bug (err on side of safety)

Inconsistency (auto-fix):

• Comments about documentation/code mismatch (e.g., docs say --id but CLI uses --card-id )

• Comments about DOM structure inconsistency (e.g., meta inside <pre> in one renderer but outside in another)

• Comments about naming differences between files

• Always verify both sides: read both the doc AND the implementation to determine which is correct

Style (auto-fix):

• CodeRabbit header markers: 🧹 Nitpick , 📝 Style

• Keywords in body: style , format , naming , convention , readability , import , unused , lint , whitespace , indentation , nit: , nit , typo , spelling , consistent , redundant

• Delegation: if the issue is about Python formatting/linting (import order, unused imports, line length), delegate to ruff check --fix and ruff format rather than manual editing

• Edge case: nit: prefix always means Style regardless of other keywords

Suggestion (report only, unless --all flag):

• CodeRabbit header markers: 🛠️ Refactor suggestion , 💡 Suggestion , 📖 Note

• Keywords in body: consider , might want to , could be , alternative , refactor , performance , optimization , simplify , extract , pattern , architecture

• Default: any comment that does not match Bug/Security or Style patterns falls here

• Edge case: suggest alone is NOT a Style keyword — it goes to Suggestion unless a suggestion code block is present (which makes it auto-fixable)

Step 6: Apply Fixes

For each actionable comment (Bug/Security, Inconsistency, and Style categories):

• Read the file at the specified path

• Locate the exact code using symbol names (not just line numbers, which shift)

• Analyze the comment body for:

• Code suggestion blocks (```suggestion markers): Apply the suggested code directly

• Descriptive feedback: Understand the issue and implement an appropriate fix

• Apply the fix to the file

• After each fix, verify the change is correct — re-read the modified code to confirm it matches the intent

For Style issues that ruff can handle:

ruff check --fix synapse/ tests/ ruff format synapse/ tests/

If --dry-run flag is provided: show each comment with its classification and proposed fix, but do NOT modify files, commit, or push.

Step 7: Local Verification

After applying all fixes:

ruff check synapse/ tests/

ruff format synapse/ tests/ --check

pytest

If any check fails after fixing:

• Attempt one targeted correction

• If it still fails, revert the problematic fix and report it as unresolvable

Step 8: Commit and Push

Stage and commit the changes:

git add -u

git commit -m "fix: address CodeRabbit review comments

Resolved:

• <summary of each fixed comment>

Reported (not auto-fixed):

• <summary of suggestion-only comments>"

git push

Step 9: Report Summary

Report what was done:

• Number of comments addressed (by category: bug, inconsistency, style, suggestion)

• Number of comments verified as already resolved or not applicable

• Files modified

• Comments left as suggestions (not auto-fixed)

• Whether all local checks pass

• Link to the PR for manual review of remaining suggestions

Error Handling

• No PR found: Report and stop

• No CodeRabbit comments: Report and stop

• gh API errors: Report the error and suggest manual review

• Fix causes test failure: Revert that specific fix, report the issue

• Never force-push: Always use git push

• Max 1 fix cycle: One pass of fixes. If issues remain, report for manual handling

Safety

• Only fixes Bug/Security, Inconsistency, and Style categories by default

• Suggestions are reported but not auto-fixed (unless --all )

• Every finding is verified against current code before fixing

• Cross-references implementation (argparse, routes, etc.) when fixing doc/code mismatches

• Local verification before pushing

• One retry per failed fix, then revert

• CodeRabbit's profile: "chill" means suggestions are advisory, not blocking