Claude Cursor Skill

review-pr

This skill should be used when user asks to "review a PR", "review pull request", "review this pr", "code review this PR", "check PR #N", provides a GitHub PR URL, or explicitly invokes "review-pr".

LLM Mart · 0 points · 8 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download fcakyon-claude-codex-settings-plugins_github-dev_skills_review-pr-4632eb3.zip · 1 KB

fcakyon/claude-codex-settings 1155 110 forks Apache-2.0 Updated 1d ago

Part of fcakyon/claude-codex-settings — 83 skills

Install

skills CLI npx skills add https://github.com/fcakyon/claude-codex-settings/tree/main/plugins/github-dev/skills/review-pr

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install fcakyon-claude-codex-settings@llmmart

Git git clone https://github.com/fcakyon/claude-codex-settings.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole fcakyon/claude-codex-settings collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Review PR

Review a pull request for bugs, regressions, missing tests, and risky changes.

When explicitly invoked with extra text, treat that text as the PR number or URL. If no PR reference is provided, infer it from the current branch.

Process

Preferred execution
- If subagents are available, use github-dev:pr-reviewer and pass the PR reference.
- Otherwise follow the manual steps below.
Parse PR reference
- If a PR number or URL is provided, extract owner, repo, and PR number.
- If not, auto-detect the PR from the current branch with gh pr view --json number,headRefName.
Fetch PR data
- Use gh pr diff <number> for the full diff.
- Use gh pr view <number> --json files for the changed file list.
- Skip generated or vendored files such as .lock, .min.js, .min.css, dist/, build/, vendor/, node_modules/, _pb2.py, and images.
Review focus
- Only report issues that require fixes.
- Only review PR changes, never pre-existing issues in unchanged code.
- Prioritize bugs, security issues, breaking changes, performance issues, edge cases, and missing tests.
- Combine related issues that share the same root cause.
- Keep the list short and high signal.
Review comment rules
- Only create pending PR comments, never submit or confirm the review automatically.
- Use gh for GitHub operations.
- Start comments in lowercase, keep them short, avoid end punctuation when possible.
- Use simple language for both bot-facing and human-facing comments.

Output Format

If issues are found, report them in descending severity with file references and a final recommendation of NEEDS_CHANGES.

If no issues are found, return APPROVE - No fixes required.

Files (claude-codex-settings)

SKILL.md 2 KB

---
name: review-pr
description: This skill should be used when user asks to "review a PR", "review pull request", "review this pr", "code review this PR", "check PR #N", provides a GitHub PR URL, or explicitly invokes "review-pr".
---

# Review PR

Review a pull request for bugs, regressions, missing tests, and risky changes.

When explicitly invoked with extra text, treat that text as the PR number or URL. If no PR
reference is provided, infer it from the current branch.

## Process

1. **Preferred execution**
   - If subagents are available, use `github-dev:pr-reviewer` and pass the PR reference.
   - Otherwise follow the manual steps below.

2. **Parse PR reference**
   - If a PR number or URL is provided, extract owner, repo, and PR number.
   - If not, auto-detect the PR from the current branch with `gh pr view --json number,headRefName`.

3. **Fetch PR data**
   - Use `gh pr diff <number>` for the full diff.
   - Use `gh pr view <number> --json files` for the changed file list.
   - Skip generated or vendored files such as `.lock`, `.min.js`, `.min.css`, `dist/`, `build/`, `vendor/`, `node_modules/`, `_pb2.py`, and images.

4. **Review focus**
   - Only report issues that require fixes.
   - Only review PR changes, never pre-existing issues in unchanged code.
   - Prioritize bugs, security issues, breaking changes, performance issues, edge cases, and missing tests.
   - Combine related issues that share the same root cause.
   - Keep the list short and high signal.

5. **Review comment rules**
   - Only create pending PR comments, never submit or confirm the review automatically.
   - Use `gh` for GitHub operations.
   - Start comments in lowercase, keep them short, avoid end punctuation when possible.
   - Use simple language for both bot-facing and human-facing comments.

## Output Format

If issues are found, report them in descending severity with file references and a final
recommendation of `NEEDS_CHANGES`.

If no issues are found, return `APPROVE - No fixes required`.