
Review Pr
- 1 installs
- 2 repo stars
- Updated April 17, 2026
- ai-builder-team/ai-builder-plugin-marketplace
review-pr is a Claude Code skill that runs a multi-agent code review on a pull request and posts validated, concise inline comments to GitHub after user approval.
About
review-pr is a Claude Code skill that runs a thorough, multi-agent code review on a pull request and posts concise inline comments to GitHub. It launches parallel review agents covering code quality, silent failures, test coverage, comment accuracy and type design, then validates each finding against the actual source. A developer uses it to get a senior-engineer-style review with casual inline comments. It requires explicit user approval before any comment is posted to GitHub.
- Runs a multi-agent code review on a PR and posts concise inline GitHub comments
- Launches parallel review agents for quality, silent failures, tests, comments and types
- Validates every finding against source and requires user approval before posting
Review Pr by the numbers
- 1 all-time installs (skills.sh)
- Ranked #984 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Jul 7, 2026 (Skillselion catalog sync)
review-pr capabilities & compatibility
Free; requires the gh CLI and GitHub access, no separate API keys.
- Capabilities
- code review · pr review · inline comments · silent failure detection · test coverage analysis
- Works with
- github
- Use cases
- code review
- Pricing
- Free
What review-pr says it does
Deep PR review with inline GitHub comments. Launches parallel review agents, validates findings, drafts casual inline comments, and posts after user approval.
**This is the most important step.** For every finding:
npx skills add https://github.com/ai-builder-team/ai-builder-plugin-marketplace --skill review-prAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 2 |
| Last updated | April 17, 2026 |
| Repository | ai-builder-team/ai-builder-plugin-marketplace ↗ |
What it does
Run a multi-agent code review on a pull request and post validated inline GitHub comments after approval.
Who is it for?
Developers who want a validated senior-engineer-style PR review with inline GitHub comments.
Skip if: Auto-posting reviews without human sign-off; it never posts before explicit approval.
When should I use this skill?
you want a deep, multi-agent review of a pull request with inline comments.
What you get
A validated set of concise inline comments and a short review body are posted to the PR after user approval.
- Validated inline PR comments with file:line targets
- A short PR review body with a COMMENT or REQUEST_CHANGES action
By the numbers
- Launches 5 parallel review agents
- Caps output at 5-7 inline comments
Files
Purpose
Run a thorough, multi-agent code review on a pull request and post concise inline comments to GitHub. The review should feel like it came from a senior engineer who actually read the code -- not a linter or AI tool.
When to use: "review this PR", "review PR #123", "give me a code review", or just /review-pr
Instructions
Step 1: Identify the PR
Parse $ARGUMENTS for a PR number. If blank, detect from the current branch:
gh pr view --json number,title,state,headRefOidThen get the scope:
git diff --name-only main...HEAD
git diff --stat main...HEAD -- '*.py' '*.ts' '*.tsx' '*.js'Tell the user the PR number, title, and file count before proceeding.
Step 2: Launch review agents in parallel
Launch ALL of the following simultaneously using the Task tool with run_in_background: true:
| Agent | subagent_type | Focus |
|---|---|---|
| Code quality | pr-review-toolkit:code-reviewer | CLAUDE.md compliance, bugs, security |
| Error handling | pr-review-toolkit:silent-failure-hunter | Silent failures, swallowed exceptions |
| Test coverage | pr-review-toolkit:pr-test-analyzer | Coverage gaps, test quality |
| Comments | pr-review-toolkit:comment-analyzer | Accuracy, staleness, misleading docs |
| Types | pr-review-toolkit:type-design-analyzer | Type invariants, design quality |
Skip the type-design-analyzer if no new types/schemas are introduced.
Each agent prompt should include:
- The PR number and branch
- Changed files relevant to that agent's specialty
- Instruction to use
git diff main...HEAD
Step 3: Collect results
Wait for all agents to complete. Read each output.
Step 4: Validate findings
This is the most important step. For every finding:
Readthe actual source code at the reported location- Confirm the issue exists as described
- Drop anything that's incorrect, already handled, or not worth commenting on
False positives destroy credibility. Be ruthless about cutting.
Step 5: Draft inline comments
Write concise, casual comments. Follow these rules:
Tone:
- Like a thoughtful colleague, not a linter
- 1-2 sentences. Get to the point.
- No corporate speak. No "I would suggest..." -- just say what's up
- "Nit:" for non-blocking. "Suggestion:" for substantial with rationale
- "Not blocking" where appropriate
Content:
- Focus on what matters: bugs, silent failures, misleading behavior, dead code
- Skip pure style nits
- Short code suggestions are fine (3-5 lines max)
- Group related issues where it makes sense
Volume:
- 5-7 comments max. Quality over quantity.
- Not every finding deserves a comment
Step 6: Draft PR review body
Short and human. Structure:
- 2-3 sentences acknowledging what's good (genuinely)
- Bullet the main concerns (2-4 bullets max)
- One-line overall assessment
- Review action:
COMMENTunless there are truly blocking issues (REQUEST_CHANGES)
Step 7: Present for approval
CRITICAL: Do NOT post to GitHub yet.
Show the user:
- All inline comments with file:line targets
- The review body
- The review action
Ask if they want to adjust anything.
Step 8: Post the review
Only after explicit approval, post as a single GitHub review:
COMMIT=$(gh pr view <PR> --json headRefOid -q '.headRefOid')
OWNER=$(gh pr view <PR> --json headRepositoryOwner -q '.headRepositoryOwner.login')
REPO=$(gh pr view <PR> --json headRepository -q '.headRepository.name')Build JSON payload:
{
"commit_id": "<COMMIT>",
"event": "COMMENT",
"body": "<review body>",
"comments": [
{
"path": "relative/path/to/file.py",
"line": 42,
"side": "RIGHT",
"body": "Comment text"
}
]
}Post via:
gh api repos/$OWNER/$REPO/pulls/<PR>/reviews \
--method POST --input /tmp/pr_review.json \
--jq '{ id: .id, state: .state, html_url: .html_url }'Return the review URL.
---
Anti-Patterns
- Posting without approval -- Never. The user must greenlight every comment.
- Trusting agent output blindly -- Always validate against actual code.
- Over-commenting -- 10 comments is too many. Prioritize.
- Sounding like AI -- No "I would recommend considering..." Just say it.
- Commenting on things you didn't verify -- If you didn't read the line, don't comment on it.
- Mixing blocking and non-blocking -- Be clear about what actually needs fixing vs nice-to-have.
---
Example Session
User: /review-pr 1724
Claude: PR #1724 "feat(eval): implement complete evaluation framework"
42 code files changed, +4512/-139 lines
Launching 5 review agents in parallel...
[agents complete]
Validated 8 findings. Here are the proposed comments:
Comment 1 - snapshot_utils.py:128
> This empty except swallows JSON parse errors and then...
Comment 2 - schemas.py:27
> This DatasetError(Exception) collides with...
[etc.]
PR Review Body:
> Solid work here -- the eval framework design is clean...
Ready to post, or want to adjust anything?
User: Comment 3 is too long, trim it
Claude: [adjusts] Updated. Ready to post?
User: Ship it
Claude: Review posted: https://github.com/.../pull/1724#pullrequestreview-...Related skills
FAQ
Does it post automatically?
No. It presents all inline comments and the review body for approval and only posts after explicit greenlight.
How does it avoid false positives?
It reads the actual source at each reported location and drops any finding that is incorrect, already handled, or not worth commenting on.