菜单
Reviews pull requests for correctness, style, and risks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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?