Menü
Reviews pull requests for correctness, style, and risks.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Diagnoses openclaude provider configuration problems and proposes fixes.
Resolves merge and rebase conflicts by preserving both sides' intent.
Reads a CodeQL or static-analysis finding and produces a targeted fix.
Fixture where a curl-piped-to-bash sits inside a fenced block; scanner must still flag it.
Reviews database schema changes, migrations, and queries.
Implements frontend components following project conventions.
| name | pr-review |
| title | PR Review |
| description | Reviews pull requests for correctness, style, and risks. |
| category | code-review |
| tags | ["review","github","quality"] |
| trust | official |
| version | 0.1.0 |
| license | MIT |
| author | gnanam |
Review a pull request the way a careful teammate would: read the actual code, group findings by severity, and make every comment actionable.
refactor-plan skill.release-maintainer skill.gh pr diff <number> and the
metadata with gh pr view <number> --json title,body,additions,deletions,files.git diff <base>...<head> --stat then
git diff <base>...<head> to see the patch.file:line (or file:line-line
for a range), describe the problem in one sentence, and either
propose a concrete fix or ask one focused clarifying question. Lead
with blockers; finish with nits. Keep the tone constructive — you
are reading the author's work, not grading it.When the PR is unusually large (more than ~600 lines changed or 20+ files touched), stop and tell the user the PR should be split before being reviewed. Reviewing a too-large PR in one pass produces a worse review than reviewing three smaller ones; saying so up front is more useful than a half-baked sweep. Offer to review each piece as the author splits it.
In scope: "Review PR #142 — adds user search."
→ Run the procedure. Fetch the diff with gh pr diff 142. Note the
6 files touched and ~180 lines added. Open each changed file in
src/search/: trace the request path from handler to repository,
check the new SQL for parameter binding, check that the new endpoint
has tests (look in tests/search/), check that pagination handles
empty result sets. Group findings:
repository.ts:42 builds the query with string
concatenation — parameterize it.handler.ts:88 returns 200 with an empty array on
invalid input — should be 400 with a message.types.ts:14 — type alias SearchRes is inconsistent
with SearchResult used elsewhere.In scope: "Summarize what PR #87 does."
→ A summary is a valid output of this skill when the user explicitly asks for one. Read the PR description and diff, then produce a 3–5 bullet summary grouped by area (API changes, schema changes, tests). Do not invent a review the user did not ask for.
Out of scope: "Write the user search feature."
→ Tell the user that pr-review reviews existing code; suggest a
coding skill (or a fresh implementation conversation) for the
implementation work. Do not start writing the feature.
Out of scope: "Tell me whether to merge this — it's a 4000-line PR across 60 files."
→ A PR this size should be split before being reviewed. Suggest the author break it into smaller PRs grouped by concern, and offer to review each piece. Do not attempt a complete review of a PR you cannot read in a sitting.
file:line reference?