🔎 pr-reviewer-pro

# Claude Code (all 51 skills)
/plugin install all-skills --marketplace milad-ahmd/agent-skills

# Cursor, Codex, Cline, Windsurf, Copilot + 75 more agents
npx skills add milad-ahmd/agent-skills --skill pr-reviewer-pro

# Shell installer
curl -fsSL https://raw.githubusercontent.com/milad-ahmd/agent-skills/main/install.sh | bash -s -- pr-reviewer-pro

PR Reviewer Pro

Give a review that a senior engineer would be proud of: few, high-signal, actionable comments.

1. Collect the diff

Use the helper script (works for both cases):

bash scripts/collect_diff.sh            # local: current branch vs default branch
bash scripts/collect_diff.sh 123        # GitHub PR #123 (needs `gh` CLI)

Then read surrounding code for every changed hunk; never review a hunk in isolation. Also read the PR description / commit messages to understand the intent.

2. Review checklist (in priority order)

Severity	Look for
🔴 Blocker	Bugs, broken logic, data loss, race conditions, unhandled errors, security holes (injection, authz bypass, secrets in code, unsafe deserialization, SSRF, XSS), breaking API changes without migration
🟠 Major	N+1 queries, unbounded loops/memory, missing input validation, missing tests for new logic, wrong abstractions, concurrency issues
🟡 Minor	Naming, readability, duplicated code, dead code, missing types, unclear errors, logging gaps
💡 Nit / Praise	Style suggestions (only if no linter covers it) and genuine praise for good work

Also check: does the change actually do what the PR says? Are docs/changelog/migrations updated?

3. Rules

• Evidence or silence. Every comment cites file:line and explains why it matters. No vague "consider refactoring".
• Suggest the fix. Include a code snippet with the proposed change whenever possible.
• Respect project conventions. Judge against the repo's existing patterns, linters and style, not your personal taste.
• Max ~10 comments. Merge duplicates; drop nits if there are blockers.
• Don't flag what tooling catches (formatting when Prettier/Black/gofmt is configured).
• If unsure, phrase it as a question rather than a claim.

4. Output format

## PR Review: <title>

**Verdict:** ✅ Approve | 💬 Approve with comments | ❌ Request changes
**Summary:** 2–3 sentences on what the PR does and overall quality.

### 🔴 Blockers
1. `path/file.ts:42`: <problem>. <why it matters>.
   ```suggestion
   <fixed code>
   ```
### 🟠 Major
### 🟡 Minor
### 💡 Nits & praise
### 🧪 Suggested tests
- <specific test case that is missing>

5. Posting to GitHub (only if the user asks)

gh pr review <number> --comment --body-file review.md          # general comment
gh pr review <number> --request-changes --body-file review.md  # if blockers exist

Always show the review to the user and get confirmation before posting.