pr-review-expert

Overview of pr-review-expert skill

What pr-review-expert does

pr-review-expert is an engineering review skill for structured pull request and merge request analysis. It is designed for reviewers who need more than style comments: blast radius analysis, security checks, breaking-change detection, performance risk review, test coverage assessment, and a prioritized reviewer-ready report.

Use the pr-review-expert skill when you want an AI assistant to inspect a diff like a careful senior reviewer, not simply summarize the PR.

Best fit for PR review workflows

This skill is strongest for GitHub PRs or GitLab MRs that touch APIs, shared libraries, database schema, authentication, payments, PII, infrastructure configuration, or other high-impact code paths. It is also useful for large PRs where reviewers need help separating blocking issues from minor suggestions.

It fits teams that already use code review but want a repeatable checklist for risk, scope, tests, and merge readiness.

What makes it different from a generic prompt

A generic “review this PR” prompt often produces scattered comments. pr-review-expert gives the agent a review framework: fetch the diff, inspect metadata, evaluate blast radius, check security-sensitive changes, compare implementation against ticket scope, and organize findings by priority.

The main tradeoff is that the skill depends heavily on the quality of the diff and context you provide. It has one primary SKILL.md file and no bundled scripts or reference packs, so your repository context matters.

How to Use pr-review-expert skill

pr-review-expert install context

Install from the source repository path:

npx skills add alirezarezvani/claude-skills --skill pr-review-expert

After installation, confirm your agent can access the skill named pr-review-expert. For manual inspection before installing, read:

engineering/skills/pr-review-expert/SKILL.md

The upstream skill does not include helper scripts, rules folders, or extra metadata files, so the install decision should be based on the workflow described in SKILL.md.

Inputs the skill needs

For best pr-review-expert usage, provide more than a pasted diff. Useful inputs include:

• PR/MR URL or number
• Base branch and target branch
• Full diff or output from gh pr diff <PR_NUMBER>
• PR title and description
• Linked Jira, Linear, GitHub issue, or product requirement
• Test output, CI failures, coverage report, or changed test files
• Any known risk areas, such as auth, billing, migrations, or public APIs

If the agent has terminal access, ask it to fetch metadata and diff with tools such as gh pr view and gh pr diff. If not, paste the relevant files and diff sections directly.

Turn a rough request into a strong prompt

Weak prompt:

Review this PR.

Stronger prompt:

Use pr-review-expert for PR Review. Review PR #142 against main. Focus on security, breaking API changes, DB migration safety, test coverage delta, and performance regressions. The ticket is PROJ-381 and the expected scope is “add team-level invite permissions.” Treat auth bypass, data exposure, migration rollback risk, and missing tests as blocking findings. Return prioritized findings with file references, merge recommendation, and follow-up questions.

This works better because it tells the skill what changed, what “correct” means, what risks matter, and how to classify findings.

Suggested review workflow

Start with PR metadata, then read the diff. Do not jump straight to comments. A practical workflow is:

1. Review title, description, linked ticket, and stated scope.
2. Inspect changed files and identify affected services, APIs, schemas, configs, and tests.
3. Read high-risk files first: auth, permission checks, DB migrations, serializers, controllers, payment flows, secrets, dependency manifests.
4. Compare implementation to requirements.
5. Check whether new behavior has tests and whether existing tests are updated.
6. Ask the skill to produce blocking findings, non-blocking suggestions, questions, and merge readiness.

For large PRs, split the review by concern: security pass, API contract pass, migration pass, test pass, then final summary.

pr-review-expert skill FAQ

Is pr-review-expert only for GitHub?

No. The source skill explicitly supports GitHub PRs and GitLab MRs. GitHub workflows are the most straightforward because the skill references common gh CLI patterns, but the same review structure applies to GitLab if you provide the merge request diff, metadata, and discussion context.

Can beginners use the pr-review-expert skill?

Yes, but beginners should treat the output as a guided review, not an automatic approval gate. The skill can explain risks and surface review areas you may miss, but you still need to verify findings against the actual codebase, framework conventions, and team standards.

When should I not use this skill?

Do not use pr-review-expert as the only review layer for production-critical security changes, legal/compliance changes, or complex architecture decisions. It is also less useful for tiny formatting-only PRs, generated-code-only changes, or PRs where you cannot provide the diff or repository context.

How is it different from CI or static analysis?

CI tells you whether configured checks passed. Static analysis finds known patterns. The pr-review-expert skill is broader: it reasons about scope, blast radius, missing tests, breaking behavior, and reviewer questions. It should complement CI, not replace linters, SAST tools, test suites, or human code ownership.

How to Improve pr-review-expert skill

Give pr-review-expert better context

The biggest quality lever is context. Include the business goal, expected behavior, affected users, rollout plan, and any prior incidents. If the PR changes permissions, say which roles should and should not gain access. If it changes an API, include expected compatibility rules.

Better input leads to fewer generic comments and more actionable findings.

Ask for findings in a review-ready format

Specify the output shape you want. For example:

• Blocking: must fix before merge
• Important: should fix or explicitly accept risk
• Minor: cleanup or maintainability
• Questions: missing context for the author
• Merge recommendation: approve, request changes, or needs more info

Ask for file paths, line references when available, reasoning, and a concrete fix suggestion. This prevents vague feedback such as “consider adding tests.”

Watch common failure modes

Common issues include over-focusing on style, missing repository-specific conventions, assuming a dependency behavior, or flagging theoretical risks without evidence. Reduce these by providing coding standards, framework version, test strategy, and examples of similar accepted PRs.

If the first pass feels too broad, ask for a second pass limited to one dimension: “Re-review only DB migration rollback safety” or “Focus only on auth bypass paths.”

Iterate after the first review

Use the first output as a triage map. For each major finding, ask the agent to verify whether the changed code actually creates the risk, identify the minimal patch, and suggest a test that would fail before the fix.

A strong follow-up prompt is:

Re-run pr-review-expert on the updated diff. Only evaluate previously blocking findings, new changes since the last review, and whether the added tests cover the original risk. Do not repeat resolved comments unless the fix is incomplete.