Review a Pull Request
Use this skill when an agent is asked to review a pull request or assess whether
it is ready to merge.
Workflow
1. Gather the PR basics
Use the GitHub MCP tools to fetch:
- the PR metadata: title, body, author, base/head refs, mergeable state,
- the changed files list and the diff (or per-file patches),
- the current review/comment threads,
- the CI status of the head commit (Actions runs).
2. Read the diff for substance
Review per file:
- correctness (logic, edge cases, error handling),
- consistency with the surrounding code and repo conventions,
- tests: are there new/changed tests? do they cover the change?
- risk: hidden behavior changes, config/tooling drift, vendored deps.
Quote specific lines when raising issues. Do not paraphrase the diff into a
summary without evaluating it.
3. Check the surrounding signals
- CI: which runs failed, and did the failure look related to the change?
- Review threads: are prior comments addressed? is anything blocking?
- Linked issues: does the PR actually close/fix what it claims?
4. Produce the review
Structure:
- Summary: what the PR does, in one or two sentences.
- Findings, each with: location (file/line), severity (blocker / should-fix /
nit), and a concrete suggestion.
- CI/test note: state (green/failing) with the failing run names.
- Verdict: approve / changes requested / comment, matching the evidence.
5. Act only when asked
Commenting, approving, or requesting changes on the PR are write actions.
Only perform them when the user explicitly asks; otherwise deliver the review as
a response. Never merge, close, or edit a PR unprompted.
1---2name: review-pull-request3description: Review a GitHub pull request systematically: read the diff, changed files, review comments, CI status, and related issues, then produce a structured review. Use when asked to review a PR, assess merge readiness, or understand what a PR changes.4---56# Review a Pull Request78Use this skill when an agent is asked to review a pull request or assess whether9it is ready to merge.1011## Workflow1213### 1. Gather the PR basics1415Use the GitHub MCP tools to fetch:1617- the PR metadata: title, body, author, base/head refs, mergeable state,18- the changed files list and the diff (or per-file patches),19- the current review/comment threads,20- the CI status of the head commit (Actions runs).2122### 2. Read the diff for substance2324Review per file:2526- correctness (logic, edge cases, error handling),27- consistency with the surrounding code and repo conventions,28- tests: are there new/changed tests? do they cover the change?29- risk: hidden behavior changes, config/tooling drift, vendored deps.3031Quote specific lines when raising issues. Do not paraphrase the diff into a32summary without evaluating it.3334### 3. Check the surrounding signals3536- CI: which runs failed, and did the failure look related to the change?37- Review threads: are prior comments addressed? is anything blocking?38- Linked issues: does the PR actually close/fix what it claims?3940### 4. Produce the review4142Structure:4344- **Summary**: what the PR does, in one or two sentences.45- **Findings**, each with: location (file/line), severity (blocker / should-fix /46 nit), and a concrete suggestion.47- **CI/test note**: state (green/failing) with the failing run names.48- **Verdict**: approve / changes requested / comment, matching the evidence.4950### 5. Act only when asked5152Commenting, approving, or requesting changes on the PR are **write** actions.53Only perform them when the user explicitly asks; otherwise deliver the review as54a response. Never merge, close, or edit a PR unprompted.55
HiAi-gg