New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Review PR

by warpdotdev in warpdotdev/common-skills

Review a pull request diff and write structured feedback to review.json for the workflow to publish.

MITAuto-check passedDevelopment

Install Review PR

skills CLI
$ npx skills add warpdotdev/common-skills --skill review-pr -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install warpdotdev/common-skills review-pr --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/warpdotdev/common-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/review-pr .claude/skills/review-pr && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
review-pr
GitHub stars
608
Token cost
~2.6k tokens
SKILL.md length
1,385 words
Files
3 (incl. scripts)
Skills in repo
28
Repo updated
First seen
Licence
MIT

At a glance

Review a pull request diff and write structured feedback to review.json for the workflow to publish.

  • Tasks that involve Pull requests
  • SKILL.md covers Context, Review Scope, Repository-specific guidance and Diff Line Annotations, plus 6 more sections
  • Runs Python scripts from its folder; calls gh

What it does

Review PR is an agent skill from warpdotdev/common-skills. Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like prdiff.txt and prdescription.txt and producing machine-readable review output instead of posting directly to GitHub.

Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 3 other files, including scripts (for example `scripts/resolve_spec_context.py` and `scripts/validate_review_json.py`).

It sits in Development, covering Pull requests. It works with GitHub. The licence is MIT.

When your agent uses it

  • Tasks that involve Pull requests

Example prompts

  • “/review-pr”

Requirements

  • Python 3

What it can do on your machine

Read from SKILL.md and the folder at commit 2a03b40. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 2 files in scripts/ (Python), which the agent can run.

    Shell commands in SKILL.md call:

    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Review PR loads about 2.6k tokens when it runs. Until then it costs about 73 tokens; SKILL.md has 1,385 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~73
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from warpdotdev/common-skills at commit 2a03b40, republished under its MIT licence (© warpdotdev). 1,385 words, ~2,598 tokens.

Download SKILL.mdSave it as .claude/skills/review-pr/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
review-pr
description
Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like pr_diff.txt and pr_description.txt and producing machine-readable review output instead of posting directly to GitHub.

Review PR Skill

Review the current pull request and write the output to review.json.

Context

  • The working directory is the PR branch checkout.
  • The workflow usually provides an annotated diff in pr_diff.txt.
  • The workflow usually provides the PR description in pr_description.txt.
  • If spec_context.md exists, it contains spec context for implementation-vs-spec validation.
  • When the prompt references .agents/skills/review-pr/scripts/resolve_spec_context.py, use that script to materialize spec_context.md on demand instead of expecting spec content to be embedded in the prompt.
  • Focus on files and lines changed by this PR.
  • Do not post comments or reviews to GitHub directly.

Review Scope

  • Prioritize correctness, security, error handling, and meaningful performance issues.
  • Treat comment quality and test quality as first-class review priorities alongside those — not as optional nits to mention only if time allows; check both against the repository's own conventions before finalizing your verdict.
  • If the consuming repository provides a local security-review-pr companion skill or the prompt requests a security pass, apply it as supplemental guidance on code PRs and fold any security findings into the same review.json rather than emitting a separate output.
  • When spec_context.md exists, use the repository's local check-impl-against-spec skill if available and treat material spec drift as a review concern.
  • Include style or nit comments only when you can provide a concrete suggestion block.
  • If a concern involves untouched code, mention it in top-level body instead of an inline comment.
  • Do not suggest adding test cases that only vary constructor inputs or struct fields when the existing test already covers the meaningful behavior. Only suggest new tests when they exercise a distinct code path or edge case.
  • When a PR is clearly a V0 or initial implementation, frame robustness suggestions (timeouts, retries, lifecycle management) as optional future work rather than blocking concerns, unless they risk correctness, security, or data loss.

Repository-specific guidance

Before reviewing, actively check whether the consuming repository ships a companion review-pr-local skill that specializes this one for its own conventions: if the prompt names one, read it there; otherwise look for one in the repository itself (for example, at .agents/skills/review-pr-local/SKILL.md, though a repository may place or name its specialization differently). If a companion exists, read it and apply its guidance as part of this review. If none turns up either way, rely on the core contract alone.

The companion is expected to specialize this skill's commenting and testing guidance with the repository's own conventions. It may never change the output JSON schema, the severity labels, the safety rules, the evidence rules, the suggestion-block constraints, or the diff-line-annotation contract described elsewhere in this skill.

Diff Line Annotations

The diff file uses these prefixes:

  • [OLD:n] for deleted lines on the old side. Use "LEFT".
  • [NEW:n] for added lines on the new side. Use "RIGHT".
  • [OLD:n,NEW:m] for unchanged context. Use "RIGHT" with line m.

Treat these annotations as the only source of truth for inline comment locations. For every inline comment you emit, first identify the exact annotated line in pr_diff.txt (or the inlined PR diff) and copy its path, side, and line number into review.json. Do not infer line numbers from prose, rendered GitHub views, file lengths, surrounding spec text, or unannotated snippets. If you cannot point to a specific [NEW:n], [OLD:n], or [OLD:n,NEW:m] line in the annotated diff, put the feedback in top-level body instead of comments.

Comment Requirements

Every comment body must start with one of these labels:

  • 🚨 [CRITICAL] for bugs, security issues, crashes, or data loss.
  • ⚠️ [IMPORTANT] for logic problems, edge cases, or missing error handling.
  • 💡 [SUGGESTION] for worthwhile improvements or better patterns.
  • 🧹 [NIT] for cleanup only when the comment includes a suggestion block.

A confirmed violation of the repository's commenting or testing guidelines can warrant ⚠️ [IMPORTANT] on its own — regardless of how clean the rest of the PR is. Do not default these to 🧹 [NIT]/💡 [SUGGESTION] just because the surrounding code looks good.

Write comments with these constraints:

  • Be concise, direct, and actionable.
  • Do not add compliments or hedging.
  • Prefer single-line comments.
  • Keep ranges to at most 10 lines.
  • Restrict inline comments to lines that appear explicitly in the annotated PR diff.
  • Only create file-level or inline comments for files that exist in this PR's diff.
  • If the relevant file or line is not part of the diff, put the feedback in top-level body instead of comments.
  • Before adding each comment object, verify that its path, side, line, and optional start_line/start_side correspond to real annotations in the same file's diff section.
Show full SKILL.md (652 more words)Show less

Suggestion Blocks

When proposing a code change, use:

suggestion
<replacement code here>

Rules:

  • Match the exact indentation of the original file.
  • Include only replacement code.
  • The block content replaces exactly the lines start_line–line inclusive. Every line inside the block becomes the new file content for that range, and GitHub leaves all other lines untouched.
  • Do not include lines outside that range. Lines above start_line and below line remain in the file; repeating them inside the block causes them to appear twice after the suggestion is committed.
  • Never open the block with a line that already appears immediately above start_line, and never close the block with a line that already appears immediately below line. If you need those lines as anchors, widen start_line or line so they are actually part of the replaced range.
  • Count brace, bracket, paren, and block-delimiter depth ({, [, (, end, etc.) across the original replaced lines and ensure the replacement ends at the same depth. Do not emit phantom closing tokens, and do not drop required ones.
  • When unsure of the surrounding context, widen start_line/line to include enough real lines from the diff rather than guessing at surrounding tokens.
  • For multi-line suggestions, set start_line and start_side to the first line, and line and side to the last line.

Output Format

Create review.json with this shape:

json
{
  "verdict": "REJECT",
  "body": "## Overview\n...\n\n## Concerns\n- ...\n\n## Verdict\nFound: 1 critical, 2 important, 3 suggestions\n\n**Request changes**",
  "comments": [
    {
      "path": "path/to/file",
      "line": 42,
      "side": "RIGHT",
      "start_line": 40,
      "start_side": "RIGHT",
      "body": "⚠️ [IMPORTANT] Short explanation\n\n```suggestion\nreplacement\n```"
    }
  ]
}

Field rules:

  • verdict is required and must be exactly the string "APPROVE" or "REJECT" (uppercase). Map your final recommendation as: Approve or Approve with nits → "APPROVE"; Request changes → "REJECT". The verdict and the human-readable recommendation in top-level body must agree.
  • Top-level body is the GitHub review body and is required. Use body, not summary, for the review overview and final recommendation.
  • comments is required and must be an array. Use an empty array when there are no inline comments.
  • path must be relative to the repository root.
  • line is required and must target the correct side.
  • start_line is optional and only for multi-line ranges. When start_line is present, start_side is required and must be "LEFT" or "RIGHT".
  • side must be "LEFT" or "RIGHT".

Body Requirements

The top-level body must include:

  • A high-level overview of the PR.
  • Important concerns and any untouched-code concerns that could not be commented inline.
  • Issue counts in the format Found: X critical, Y important, Z suggestions.
  • A final recommendation of Approve, Approve with nits, or Request changes. This recommendation must match the top-level verdict field (Approve / Approve with nits → "APPROVE"; Request changes → "REJECT").

Pre-Verdict Audit

Before drafting the top-level body or choosing verdict, complete this audit — a holistic read-through of the diff is not sufficient.

  • Comments: List every comment (doc comment or inline) the diff adds or changes, one by one with its file:line. For each one, check it individually against the repository's own commenting guidelines, whatever form those take — or, if the repository defines none, judge it against the commenting distribution of existing code in the project (density, tone, what existing comments explain vs. omit). Evaluate compliance independently of the comment's writing quality, technical accuracy, or how subtle/important the issue it describes is: none of those qualities excuses a violation of an applicable guideline or a clear mismatch with the codebase's own norms.
  • Tests: Check every test the diff adds or changes against the repository's own testing guidelines, whatever form those take.

Final Checks

Before returning or uploading review.json:

  • Fix invalid JSON if validation fails.
  • Confirm line numbers match the annotated diff.
  • Run the bundled validator against the exact annotated diff you reviewed:
    sh
    python3 .agents/skills/review-pr/scripts/validate_review_json.py --review-json review.json --diff pr_diff.txt
    If the script reports any invalid comments, fix review.json and rerun it. Do not return or upload review.json until this validator passes. If the script path is not present at that exact location, locate validate_review_json.py under the loaded review-pr skill directory and run that copy with the same arguments.
  • Do not run gh pr review, gh pr comment, gh api, or any other command that posts to GitHub.

Your only output is the final review.json.

© warpdotdev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files (scripts) in .agents/skills/review-pr of warpdotdev/common-skills.

  • SKILL.md
  • scripts/resolve_spec_context.py
  • scripts/validate_review_json.py

Open the folder on GitHubat commit 2a03b40

Compare with similar skills

Review PR next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Review PR compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Review PR this skillwarpdotdev/common-skills608—~2.6kAutomated safety check: PassMIT
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Check PRonyx-dot-app/onyx32k2 repos~2.3kAutomated safety check: PassMIT
Contributor-First PR MergeHKUDS/OpenHarness16k1 repos~847Automated safety check: PassMIT
Create Pull Requestcline/cline70k1 repos~1.6kAutomated safety check: PassApache-2.0
Pull Request Title and Body Writeropeninterpreter/openinterpreter69k2 repos~1.1kAutomated safety check: PassApache-2.0

Similar skills

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed

  • Check PR

    onyx-dot-app/onyx

    Checks a GitHub, GitLab, or Perforce (p4) pull request (or merge request, or shelved changelist) for unresolved review comments, failing status checks, and incomplete PR descriptions.

    32k GitHub starsUsed in 2 repos~2.3k tokens
    DevelopmentAuto-check passed

  • Contributor-First PR Merge

    HKUDS/OpenHarness

    Merges external GitHub pull requests while keeping the original author credited, and fixes conflicts after the merge instead of rewriting the contribution.

    16k GitHub starsUsed in 1 repo~847 tokens
    DevelopmentAuto-check passed

  • Create Pull Request

    cline/cline

    Opens a GitHub pull request from your current branch with the gh CLI, after reviewing the commits and diff and gathering the details the PR needs.

    70k GitHub starsUsed in 1 repo~1.6k tokens
    DevelopmentAuto-check passed

  • Pull Request Title and Body Writer

    openinterpreter/openinterpreter

    Rewrites the title and body of one or more pull requests with gh, leading with why the change was made, then what changed, and describing only the net result.

    69k GitHub starsUsed in 2 repos~1.1k tokens
    DevelopmentAuto-check passed

  • GitHub Review Iteration

    prisma/orm

    Official

    Runs a loop on a GitHub pull request: fetch review state, triage comments into actions, implement them and resolve threads, repeating until nothing actionable is left.

    48k GitHub stars~2.2k tokensUpdated today
    DevelopmentAuto-check passed

More from warpdotdev/common-skills

All 28 skills in this repo

  • Skill Doctor

    warpdotdev/common-skills

    Grades agent skills by scoring agent conversations for efficiency, code quality, procedure compliance, and verbosity, then drafts concrete skill edits and a shareable report.

    608 GitHub starsUsed in 2 repos~2.6k tokens
    Auto-check passed

  • Readout

    warpdotdev/common-skills

    Produce a polished, self-contained HTML "readout" document under ~/.readouts (with an auto-maintained index page), either by snapshotting the findings accumulated in the current conversation or —…

    608 GitHub stars~2k tokensUpdated today
    Auto-check passed

  • Resolve Merge Conflicts

    warpdotdev/common-skills

    Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context.

    608 GitHub stars~733 tokensUpdated today
    Auto-check passed

  • Saga

    warpdotdev/common-skills

    Run an autonomous, spec-driven development "saga" for medium-to-large features using an orchestrator agent and a fleet of worker subagents.

    608 GitHub stars~4.1k tokensUpdated today
    Auto-check passed

  • PR Walkthrough

    warpdotdev/common-skills

    Generate a static interactive D3 walkthrough of a pull request.

    608 GitHub starsUsed in 1 repo~7.2k tokens
    Auto-check passed

  • Update Skill

    warpdotdev/common-skills

    Create or update skills by generating, editing, or refining SKILL.md files in this repository.

    608 GitHub stars~1.2k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Review PR

What does Review PR do?

Review a pull request diff and write structured feedback to review.json for the workflow to publish. Review PR is an agent skill from warpdotdev/common-skills.json for the workflow to publish.

When should I use Review PR?

Review PR fits situations like: tasks that involve Pull requests.

How do I install Review PR in Claude Code?

Run `npx skills add warpdotdev/common-skills --skill review-pr -a claude-code`. Or copy the skill folder (.agents/skills/review-pr in warpdotdev/common-skills) into .claude/skills/review-pr in your project. Claude Code loads it when a task matches its description.

How do I install Review PR in Codex?

Run `npx skills add warpdotdev/common-skills --skill review-pr -a codex`. Or copy the skill folder (.agents/skills/review-pr in warpdotdev/common-skills) into .agents/skills/review-pr in your project. Codex loads it when a task matches its description.

Can I use Review PR in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add warpdotdev/common-skills --skill review-pr -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/review-pr, .gemini/skills/review-pr, .github/skills/review-pr and .opencode/skills/review-pr in your project.

What does Review PR need to run?

Going by SKILL.md and its folder, Review PR needs Python for the scripts in its folder and the command-line tools its instructions call (gh). Our summary lists: Python 3.

Does Review PR access the network?

SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Review PR safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Review PR use?

Review PR is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Review PR use?

About 2.6k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Review PR?

Skills that share tags, products or a category with Review PR: PR Babysitter (openinterpreter/openinterpreter, 69k stars), Check PR (onyx-dot-app/onyx, 32k stars), Contributor-First PR Merge (HKUDS/OpenHarness, 16k stars) and Create Pull Request (cline/cline, 70k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Review PR?

warpdotdev (a GitHub organization) maintains it in warpdotdev/common-skills, which has 608 GitHub stars. The repository holds 28 skills in this directory. The repository was last updated on October 7, 2026.

Source: warpdotdev/common-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.