| name | review-branch-or-pr |
| description | Use when: reviewing a pull request, PR, branch, diff, or code changes for bugs, regressions, risky behavior, missing tests, or merge issues. Review the changes in a specific branch or PR against its base branch and report findings first with severity and file references. |
Branch Or PR Review
Overview
This skill performs a code review of the changes introduced by a specific branch or pull request.
The review should compare the target branch or PR against its base, inspect the changed files and diff, and then report concrete findings in code-review format.
When to Use
- The user asks for a PR review
- The user asks for a branch review
- The user asks to review code changes before merge
- The user asks for bugs, regressions, or missing tests in a diff
Review Standard
Default to a code review mindset:
- Prioritize correctness, regressions, and behavior changes
- Look for missing validation, broken assumptions, unsafe refactors, and compatibility risks
- Check whether tests cover the changed behavior when that is reasonably expected
- Keep summaries brief and place findings first
Do not default to style-only comments unless they hide a functional or maintainability risk.
Workflow
Step 1: Identify the Review Target
Determine whether the user wants to review:
- the current branch
- a named branch
- a specific PR number
- a PR URL
If the user does not specify a target and a current branch can be determined from git context, use that. Otherwise, ask the user to specify the branch or PR to review.
If the base branch is not specified, infer it from repository context when possible. Otherwise use the repository default branch.
If neither the base branch nor the repository default branch can be determined, stop and ask the user: "What is the base branch to compare against?" Do not proceed with a review against an assumed base.
Step 2: Collect the Comparison Surface
Gather the smallest useful comparison surface first:
- Identify the base branch and review target
- Compute the merge base when reviewing a branch
- List changed files before reading large diffs
- Inspect the patch for the most relevant files
If the changed file count exceeds ~50 files or the diff exceeds ~2000 lines, explicitly state the scope limitation, focus review on the highest-risk files identified in Step 3, and note in Open Questions that a full review was not performed.
Prefer repository-aware tools when available. Otherwise use git locally.
Useful commands:
git status --short
git branch --show-current
git diff --name-only <base>...<target>
git diff --stat <base>...<target>
git diff <base>...<target> -- <path>
For PR review, prefer metadata that reveals:
- the PR base branch
- the PR head branch
- the changed files
- the patch or combined diff
Step 3: Review the Deciding Code Paths
Review the files that actually control behavior, not just call sites or registrations.
Prioritize:
- Logic that computes or mutates state
- Validation and boundary handling
- Error handling and fallback behavior
- Tests added or omitted for behavior changes
- Public API or data model changes
If a changed file is mostly wiring, step once to the code that directly decides behavior.
Step 4: Form Findings
A valid finding should include:
- The concrete risk or bug
- Why it happens from the diff
- The user-visible or maintenance impact
- A precise file reference
Good findings are specific and falsifiable. Avoid vague comments like "this might be cleaner".
Focus on issues such as:
- broken control flow
- incorrect assumptions after refactors
- missing guard clauses
- inconsistent state updates
- incomplete rename or migration work
- missing or weak tests for the changed behavior
- branch-specific merge hazards
Step 5: Validate When Needed
When a likely defect depends on behavior that can be checked cheaply, run a narrow validation:
- the most relevant unit test
- a targeted lint or typecheck
- a focused command that falsifies the concern
Do not broaden into full-suite validation unless the review risk justifies it.
Response Format
Present findings first, ordered by severity.
Use this structure:
Findings
1. [severity] Short title
Why it is a problem, impact, and file reference.
Open Questions
- Any assumptions that could not be verified.
Change Summary
- Very brief overview of what changed.
If there are no findings, say so explicitly and mention residual risks or testing gaps.
Severity Guide
- high: likely bug, regression, data loss, crash, or broken workflow
- medium: correctness risk, edge-case breakage, incomplete handling, or test gap around important behavior
- low: minor maintainability concern with plausible future risk
Example Prompts
- "Review this PR for regressions."
- "Do a code review of branch
feature/search-refactor."
- "Review the changes in PR #42 against main."
- "Check whether this branch is safe to merge."
Important Rules
- Start from the diff, not from broad repository exploration
- Review the target against its actual base branch
- Findings must come before summary
- Prefer concrete bugs and regressions over style suggestions
- Run focused validation when it can confirm or disconfirm a concern cheaply
