coderabbit-review
starsforks
How to install coderabbit-review?
opendatahub-io/ai-helpers/coderabbit-review
$npx -y skills add opendatahub-io/ai-helpers --skill coderabbit-reviewUse when you need to evaluate CodeRabbit PR comments and fix or reply
SKILL.md
| 1 | # CodeRabbit PR Review Handler |
| 2 | |
| 3 | Fetch CodeRabbit comments from a GitHub PR, evaluate each one, and take action: apply a code fix or post a reply. |
| 4 | |
| 5 | **PR:** $ARGUMENTS |
| 6 | |
| 7 | ## Step 1: Resolve the PR and Repository |
| 8 | |
| 9 | Determine the `owner`, `repo`, and `pullNumber`: |
| 10 | |
| 11 | - If `$ARGUMENTS` is a PR number, use it directly. |
| 12 | - Otherwise, detect the PR from the current branch using `gh pr view` or `gh pr list`. |
| 13 | - Use `gh repo view --json owner,name` to get the upstream coordinates. If that fails (e.g., no default remote set), fall back to parsing `git remote -v` to identify the upstream GitHub repository. |
| 14 | - The repo may be a fork with multiple remotes. Do not assume names like `upstream`/`origin`. Prefer repo coordinates from PR metadata (`gh pr view --json`), then `gh repo view`, then `git remote -v`. If multiple candidates remain, ask the user. |
| 15 | - If you cannot determine the PR automatically, ask the user. |
| 16 | |
| 17 | ## Step 2: Fetch CodeRabbit Comments |
| 18 | |
| 19 | **Inline review comments** (CodeRabbit's line-level suggestions): |
| 20 | ```bash |
| 21 | gh api --paginate repos/<owner>/<repo>/pulls/<pullNumber>/comments |
| 22 | ``` |
| 23 | |
| 24 | **PR-level comments** (CodeRabbit's summary/walkthrough): |
| 25 | ```bash |
| 26 | gh api --paginate repos/<owner>/<repo>/issues/<pullNumber>/comments |
| 27 | ``` |
| 28 | |
| 29 | Filter both lists to only comments where `user.login` equals `coderabbitai[bot]`. |
| 30 | |
| 31 | For PR-level comments, skip any comment whose body contains `<!-- walkthrough_start -->` or `<!-- This is an auto-generated comment: review in progress` — these are CodeRabbit's walkthrough/summary posts, not actionable review feedback. |
| 32 | |
| 33 | For inline comments, skip any comment that belongs to a resolved review thread (check the `pull_request_review_id` against resolved threads, or look for the `"resolved": true` marker if available). |
| 34 | |
| 35 | If no actionable CodeRabbit comments are found, report that and exit. |
| 36 | |
| 37 | ## Step 3: Evaluate Each Comment |
| 38 | |
| 39 | For each CodeRabbit comment, analyze it carefully by reading the relevant source file(s). |
| 40 | |
| 41 | For inline comments: use the `path` field to read the file with the Read tool. Use `line` or `original_line` to find the exact code location. The `diff_hunk` field shows the surrounding context. |
| 42 | |
| 43 | Evaluate: |
| 44 | |
| 45 | 1. **Category**: classify as one of: |
| 46 | - `bug` — actual code defect or logic error |
| 47 | - `security` — security vulnerability |
| 48 | - `performance` — inefficiency or resource issue |
| 49 | - `style` — formatting, naming, readability |
| 50 | - `docs` — missing or incorrect documentation/comments |
| 51 | - `nitpick` — minor preference, not a real issue |
| 52 | - `question` — CodeRabbit is asking for clarification |
| 53 | |
| 54 | 2. **Validity**: does the comment point to a real issue? |
| 55 | - `valid` — yes, should be addressed |
| 56 | - `debatable` — reasonable disagreement exists |
| 57 | - `invalid` — the code is correct and CodeRabbit is wrong |
| 58 | |
| 59 | 3. **Recommended action**: |
| 60 | - `fix` — the code should be changed; generate the fix |
| 61 | - `reply` — explain why the code is correct, or acknowledge and defer |
| 62 | - `dismiss` — noise; briefly acknowledge and move on |
| 63 | |
| 64 | ## Step 4: Present Summary and Batch Decision |
| 65 | |
| 66 | Show a summary table first: |
| 67 | |
| 68 | # CodeRabbit Comments on PR #<N> |
| 69 | |
| 70 | | # | File | Line | Category | Validity | Recommended Action | Summary | |
| 71 | |---|------|------|----------|----------|--------------------|---------| |
| 72 | | 1 | src/foo.ts | 42 | bug | valid | fix | "Variable x may be undefined" | |
| 73 | | 2 | src/bar.ts | 10 | nitpick | debatable | reply | "Use const here" | |
| 74 | |
| 75 | Then show the full evaluation for each comment (bugs and security first, then performance, then others): |
| 76 | |
| 77 | --- |
| 78 | |
| 79 | ## Comment #N — [Category] — [File:Line or PR-level] |
| 80 | |
| 81 | **CodeRabbit says:** |
| 82 | > [exact quote] |
| 83 | |
| 84 | **Context** (relevant code snippet): |
| 85 | ```text |
| 86 | [code from the file at that location] |
| 87 | ``` |
| 88 | |
| 89 | **Assessment:** |
| 90 | [Your evaluation: why valid/invalid, what the actual issue is] |
| 91 | |
| 92 | **Proposed action:** `fix` | `reply` | `dismiss` |
| 93 | |
| 94 | <!-- skillsaw-disable content-placeholder-text --> |
| 95 | [If `fix`: show the exact code diff to apply] |
| 96 | |
| 97 | [If `reply` or `dismiss`: show the draft reply text] |
| 98 | |
| 99 | --- |
| 100 | |
| 101 | After presenting ALL comments, **wait for the user to respond**. The user may want to: |
| 102 | |
| 103 | - **Discuss** — ask questions, understand a comment better, debate whether it's valid. Act as a knowledgeable colleague: explain the trade-offs, share context, help them form their own opinion. Stay in this discussion mode as long as the user is engaging. Do NOT push toward action or present menus while the user is still exploring. |
| 104 | - **Act** — when the user indicates they're ready (e.g., "let's fix these", "go ahead", "apply #1 and #3"), proceed with the requested actions. |
| 105 | - **Decide per-comment** — if the user wants to go through comments one by one, walk through each and ask what to d |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
