| name | github-review |
| description | Review a GitHub pull request for correctness, consistency, edge cases, and test coverage. Post findings on the PR or linked issue. No code changes. |
| scopes | ["main"] |
GitHub Review
Review a GitHub pull request. Your job is code review only. Do not push commits or modify the PR branch.
Use the gh CLI for GitHub operations: gh pr view, gh pr diff, gh pr review, gh issue view, and gh issue comment.
Phase 1: Find the PR
Identify the pull request to review.
- If the user provided a PR number or URL, use that directly.
- Otherwise look for a PR linked from the relevant GitHub issue.
- If needed, search by branch name, issue number, or title with
gh pr list --search.
- If no PR is found, report that and stop.
Phase 2: Understand the Context
Before reviewing code:
- Read the PR title, body, and linked issue.
- Re-read the issue body to understand what the PR is supposed to accomplish.
- Note any definition of done, implementation prompt, or explicit test cases.
- Check for an existing
## Code Review section or prior review comments. If a previous review already exists, focus on changes made since that review instead of redoing everything.
Phase 3: Review the Code
Read the full diff carefully with gh pr diff.
Review Checklist
Correctness
- Does the code do what the issue asks?
- Are there logic errors, missed branches, or broken assumptions?
- Are failure cases handled cleanly?
- Are there race conditions, async hazards, or ordering problems?
Edge Cases
- Null or undefined inputs
- Empty collections
- Boundary values
- Malformed or unexpected data
Style and Consistency
- Does it follow existing repo patterns?
- Are names and structure aligned with nearby code?
- Is the new code in the right place?
- Are unrelated changes avoided?
Performance
- N+1 queries or needless loops
- Large or repeated allocations
- Missing pagination or bounds on unbounded lists
- Unnecessary network or disk work
Security
- Input validation at boundaries
- Auth or authorization gaps
- Injection risks
- Sensitive data exposure in logs or responses
Tests
- Are there tests for the important behavior?
- Do tests cover the key scenarios from the issue?
- Are tests behavior-focused instead of implementation-coupled?
- Any obvious flaky test patterns?
Phase 4: Post the Review
Post the review directly on the PR with gh pr review. If there is a linked issue and the findings materially affect scope or acceptance, add a concise summary there as well.
Review Format
## Code Review
### Verdict: [Approve / Request Changes / Needs Discussion]
### Summary
[1-2 sentence overall assessment]
### Findings
#### [Critical / Important / Suggestion] - [Short title]
**File:** `path/to/file.ts:42`
**Issue:** [What is wrong]
**Suggestion:** [How to fix it]
### What Looks Good
[Patterns, implementation details, or tests that are solid]
### Test Coverage Assessment
[Is coverage sufficient? What is missing?]
Use Approve for clearly correct low-risk work, Request Changes for concrete blocking issues, and Needs Discussion when the main problem is product or design ambiguity rather than an obvious bug.
Output Summary
After posting the review, respond with:
- Verdict
- Number of findings by severity
- One-sentence summary
Notes
- Be specific: cite files, lines, and concrete failure modes
- Distinguish blockers from suggestions
- Explain why something is a problem, not just that it looks wrong
- Call out good work when it is materially helpful
- If the PR is trivially correct, keep the review short and approve it
