github-review

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.

1. If the user provided a PR number or URL, use that directly.
2. Otherwise look for a PR linked from the relevant GitHub issue.
3. If needed, search by branch name, issue number, or title with gh pr list --search.
4. If no PR is found, report that and stop.

Phase 2: Understand the Context

Before reviewing code:

1. Read the PR title, body, and linked issue.
2. Re-read the issue body to understand what the PR is supposed to accomplish.
3. Note any definition of done, implementation prompt, or explicit test cases.
4. 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:

1. Verdict
2. Number of findings by severity
3. 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