Agent skill · software engineering · jeremylongshore
review-pr
Reviews an open pull request against coding standards, security, and test coverage, then posts a structured review comment and either approves or requests changes. Use when the user says review this PR, check the PR, look at PR #N, or review pull request.
Why this skill is useful
Adds a complete executable script for reviewing pull requests, including checks for coding standards, security, and test coverage that are not commonly found in public documentation.
What it needs
Requires gh installed locally. About 3k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Review PR PR: !gh pr view --json number,title --jq '"#\(.number): \(.title)"' 2>/dev/null echo "none" Fetches a pull request diff, evaluates it against the project's coding standards, security posture, and test coverage, then posts a structured review and either approves or requests changes. Step 0: Pre-flight check Determine the PR to review. If the user named a number, use it. Otherwise default to the current branch's open PR: If no PR is found, stop and ask the user which PR number to review. Step 1: Fetch PR context Also read the project files to understand standards and conventions: README.md — stated purpose and feature set CLAUDE.md — current decisions and context, if present ~/.claude/CLAUDE.md — personal development standards already loaded in context Step 2: Evaluate the diff Review the diff against the following criteria. Note findings — positive and negative — for each: Correctness Does the change do what the PR description says? Are there logic errors, off-by-one errors, or incorrect conditionals? Are edge cases handled? Coding standards (from ~/.claude/CLAUDE.md) Scripts use correct shebang and follow the Bash Style Guide Terminal output uses pfb (Bash) or Rich (Python) with correct visual hierarchy Functions have Google-style documentation headers No hardcoded configuration — environment variables with .env.template Error messages are actionable (say what went wrong and what to do) Security No secrets, credentials, or tokens in code or comments External input validated at system boundaries No command injection risks (unquoted variables in shell, unsanitised input in queries) File paths handled safely (no unquoted expansions, no eval on external data) Test coverage Are new code paths exercised by tests? Do existing tests still pass (check for any test files modified or added)? Are failure paths tested, not just happy paths? Documentation and markdown New or changed markdown passes markdownlint conventions (blank lines around blocks, language on code fe …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/review-pr