Rating
Votes
0
score
Downloads
0
total
Price
Free
No login needed
Works With
About
Type /review-pr (or /review-pr 123) and your AI checks out the branch, reads the diff, and gives you a real review — security, performance, edge cases, naming, missing tests. Each comment tagged blocker / suggestion / nit so you know what actually matters.
Don't lose this
Three weeks from now, you'll want PR Reviewer again. Will you remember where to find it?
Save it to your library and the next time you need PR Reviewer, it’s one tap away — from any AI app you use. Group it into a bench with the rest of the team for that kind of task and you can pull the whole stack at once.
⚡ Pro tip for geeks: add a-gnt 🤵🏻♂️ as a custom connector in Claude or a custom GPT in ChatGPT — one click and your library is right there in the chat. Or, if you’re in an editor, install the a-gnt MCP server and say “use my [bench name]” in Claude Code, Cursor, VS Code, or Windsurf.
a-gnt's Take
Our honest review
Think of this as teaching your AI a new trick. Once you add it, get a thorough code review with severity tags before you ship — no extra apps or complicated setup needed. It's verified by the creator and completely free. This one just landed in the catalog — worth trying while it's fresh.
Tips for getting started
Save this as a .md file in your project folder, or paste it into your CLAUDE.md file. Your AI will automatically use it whenever the skill is relevant.
Soul File
---
name: review-pr
description: Thorough PR review. Reads the diff, checks for bugs, security issues, missing tests, and code smells. Tags every comment by severity.
---
Usage: `/review-pr` (reviews current branch vs main) or `/review-pr 123` (reviews PR #123 via gh).
## Procedure
1. **Get the diff.**
- If a PR number is given: `gh pr checkout <num>` then `gh pr diff <num>`
- Otherwise: `git diff main...HEAD`
2. **Read the surrounding context.** Don't review files in isolation. Open the files being changed and read the functions/classes that touch the changed lines.
3. **Run the review.** For each meaningful change, ask:
- **Correctness** — does this actually do what the PR title claims? Edge cases?
- **Security** — input validation, auth checks, SQL injection, XSS, secrets in code, race conditions
- **Performance** — N+1 queries, accidental loops, missing indexes, memory leaks
- **Tests** — are new code paths tested? Are existing tests updated?
- **Naming & clarity** — would a future reader understand this?
- **Consistency** — does this match patterns elsewhere in the repo?
## Output format
Group findings by severity. Use these exact tags:
- **🚫 BLOCKER** — must fix before merge. Bug, security issue, broken test, breaking change.
- **⚠️ SUGGESTION** — should consider. Better approach, missing test, unclear naming.
- **💭 NIT** — minor. Style, micro-optimization, optional polish.
Each comment:
```
🚫 BLOCKER — path/to/file.ts:42
The query inside the loop runs N+1 times. Move it outside or batch it.
```
## At the end
- **Summary** — 2-3 sentences on overall quality.
- **Verdict** — APPROVE / REQUEST_CHANGES / COMMENT
- **The one thing** — if the author only fixes one thing, what should it be?
## Never
- Never approve a PR with a BLOCKER.
- Never invent issues to seem thorough. If the PR is good, say it's good.
- Never review the test file's tests for the test file. Stay focused.What's New
Initial release
Ratings & Reviews
0.0
out of 5
0 ratings
No reviews yet. Be the first to share your experience.