PR Review
Review a GitHub PR's diff and submit a single GitHub review with inline comments identifying bugs, performance issues, security concerns, and improvements.
Arguments
$ARGUMENTS (optional): The PR number to review. If not provided, detect the PR associated with the current branch.
Step 1: Identify the PR
- Get the repository:
gh repo view --json nameWithOwner -q '.nameWithOwner'
- If a PR number was provided in
$ARGUMENTS, use it directly.
- If no PR number was provided, detect the PR for the current branch:
gh pr list --head "$(git branch --show-current)" --json number,title,url --limit 1
- If no PR is found, inform the user and stop.
- Fetch PR metadata:
gh pr view <NUMBER> --json number,title,url,headRefName,baseRefName,author,body
- Show the PR title and URL for confirmation before proceeding.
Step 2: Fetch the Diff and Changed Files
- Get the full diff:
gh pr diff <NUMBER>
- Get the list of changed files with line counts:
gh pr view <NUMBER> --json files --jq '.files[] | "\(.path) +\(.additions) -\(.deletions)"'
Step 3: Analyze Each Changed File
For each changed file in the diff:
- Read the full file for context (not just the diff) using the Read tool.
- Understand the purpose of the changes from the diff hunks and surrounding code.
- Review for issues across these categories:
| Tag |
What to look for |
| 🔴 Critical |
Bugs, logic errors, incorrect behavior, data loss risks |
| 🔒 Security |
Injection, auth bypass, secrets exposure, unsafe deserialization |
| ⚡ Performance |
N+1 queries, unnecessary re-renders, memory leaks, O(n²) when O(n) is possible |
| 🐛 Bug |
Null pointer risks, off-by-one errors, race conditions, unhandled errors |
| ✨ Improvement |
Clearer naming, better patterns, simpler logic, unnecessary complexity |
| 🧪 Testing |
Missing test cases, untested edge cases, weak assertions |
| 📝 Documentation |
Missing/incorrect JSDoc, misleading comments, unclear intent |
- Trace dependencies — use Grep/Glob to check callers, interfaces, and types affected by the change when relevant.
- Check the PR description — verify the code matches what the author says they changed.
Review guidelines
- Focus on substantive issues — skip formatting nitpicks, trivial style preferences, and obvious code.
- Every comment must be actionable — say what to change, not just what's wrong.
- Include a concrete code suggestion when possible.
- Be respectful and constructive. Assume the author is competent.
- Don't comment on unchanged code unless a change introduces an issue with it.
- For large PRs (20+ files), prioritize critical and security issues. Mention that a full review is recommended.
Step 4: Present Findings
Display ALL findings sorted by severity (critical first), then by file order in the diff.
For each finding:
### #N — [TAG] file/path.ts:L<line>
**Issue**: [Clear, concise description of the problem]
**Suggestion**: [Concrete fix or code change]
After presenting all findings:
- Show a summary count:
Found X issues: N critical, N security, N bugs, N improvements...
- If no issues found, say so clearly.
Then ask:
Ready to submit this review? Enter "yes" to post all comments, "remove N,N" to drop specific items, or "edit N" to modify a comment before posting.
Step 5: Submit the Review
Submit a single review using the GitHub API with event COMMENT:
gh api repos/{owner}/{repo}/pulls/{number}/reviews --method POST --input /tmp/pr-review-payload.json
Build the JSON payload with all comments. Each comment needs:
path: file path relative to repo root
line: the line number in the diff (use the new file line number for added/modified lines)
side: "RIGHT" for comments on the new version of the code
body: the review comment text with tag, issue description, and suggestion. Always append \n\n---\n_[Generated by AI]_ at the end of every comment body
Building the review payload
Construct a temporary JSON file with the review data:
{
"event": "COMMENT",
"body": "Review summary — found N issues across M files.",
"comments": [
{
"path": "src/auth.ts",
"line": 45,
"side": "RIGHT",
"body": "🔴 **Critical**: Missing null check on `user` before accessing `.id`. This will throw if the query returns no results.\n\n**Suggestion**:\n```ts\nif (!user) {\n throw new NotFoundError('User not found');\n}\n```\n\n---\n_[Generated by AI]_"
}
]
}
Submit with:
gh api repos/{owner}/{repo}/pulls/{number}/reviews --method POST --input /tmp/pr-review-payload.json
Clean up the temp file after submission.
Line number mapping
- For comments on added or modified lines: use the line number from the new file (
+ side of the diff), set side: "RIGHT".
- For comments on deleted lines: use the line number from the old file (
- side of the diff), set side: "LEFT".
- To find the correct line number, parse the diff hunk headers (
@@ -old_start,old_count +new_start,new_count @@) and count lines from there.
Step 6: Confirmation
After successful submission:
## Review Submitted
PR #<number> — <title>
URL: <review URL>
Posted <N> inline comments across <M> files.
If submission fails, show the error and suggest the user check their gh auth permissions.
1---2name: pr-review-23description: Review a GitHub Pull Request and submit a single review with inline code comments. Identifies bugs, security vulnerabilities, performance issues, logic errors, missing edge cases, and suggests improvements. Use when the user wants to review a PR, do a code review, or add review comments to a pull request.4---5
6# PR Review
7
8Review a GitHub PR's diff and submit a single GitHub review with inline comments identifying bugs, performance issues, security concerns, and improvements.
9
10## Arguments
11
12- `$ARGUMENTS` (optional): The PR number to review. If not provided, detect the PR associated with the current branch.
13
14## Step 1: Identify the PR
15
161. Get the repository:
17 ```bash
18 gh repo view --json nameWithOwner -q '.nameWithOwner'
19 ```
202. If a PR number was provided in `$ARGUMENTS`, use it directly.
213. If no PR number was provided, detect the PR for the current branch:
22 ```bash
23 gh pr list --head "$(git branch --show-current)" --json number,title,url --limit 1
24 ```
254. If no PR is found, inform the user and stop.
265. Fetch PR metadata:
27 ```bash
28 gh pr view <NUMBER> --json number,title,url,headRefName,baseRefName,author,body
29 ```
306. Show the PR title and URL for confirmation before proceeding.
31
32## Step 2: Fetch the Diff and Changed Files
33
341. Get the full diff:
35 ```bash
36 gh pr diff <NUMBER>
37 ```
382. Get the list of changed files with line counts:
39 ```bash
40 gh pr view <NUMBER> --json files --jq '.files[] | "\(.path) +\(.additions) -\(.deletions)"'
41 ```
42
43## Step 3: Analyze Each Changed File
44
45For each changed file in the diff:
46
471. **Read the full file** for context (not just the diff) using the Read tool.
482. **Understand the purpose** of the changes from the diff hunks and surrounding code.
493. **Review for issues** across these categories:
50
51| Tag | What to look for |
52|-----|-----------------|
53| 🔴 Critical | Bugs, logic errors, incorrect behavior, data loss risks |
54| 🔒 Security | Injection, auth bypass, secrets exposure, unsafe deserialization |
55| ⚡ Performance | N+1 queries, unnecessary re-renders, memory leaks, O(n²) when O(n) is possible |
56| 🐛 Bug | Null pointer risks, off-by-one errors, race conditions, unhandled errors |
57| ✨ Improvement | Clearer naming, better patterns, simpler logic, unnecessary complexity |
58| 🧪 Testing | Missing test cases, untested edge cases, weak assertions |
59| 📝 Documentation | Missing/incorrect JSDoc, misleading comments, unclear intent |
60
614. **Trace dependencies** — use Grep/Glob to check callers, interfaces, and types affected by the change when relevant.
625. **Check the PR description** — verify the code matches what the author says they changed.
63
64### Review guidelines
65
66- Focus on **substantive issues** — skip formatting nitpicks, trivial style preferences, and obvious code.
67- Every comment must be **actionable** — say what to change, not just what's wrong.
68- Include a **concrete code suggestion** when possible.
69- Be respectful and constructive. Assume the author is competent.
70- Don't comment on unchanged code unless a change introduces an issue with it.
71- For large PRs (20+ files), prioritize critical and security issues. Mention that a full review is recommended.
72
73## Step 4: Present Findings
74
75Display ALL findings sorted by severity (critical first), then by file order in the diff.
76
77For each finding:
78
79```md
80### #N — [TAG] file/path.ts:L<line>
81**Issue**: [Clear, concise description of the problem]
82**Suggestion**: [Concrete fix or code change]
83```
84
85After presenting all findings:
86
87- Show a summary count: `Found X issues: N critical, N security, N bugs, N improvements...`
88- If no issues found, say so clearly.
89
90Then ask:
91
92> **Ready to submit this review?** Enter "yes" to post all comments, "remove N,N" to drop specific items, or "edit N" to modify a comment before posting.
93
94## Step 5: Submit the Review
95
96Submit a single review using the GitHub API with event `COMMENT`:
97
98```bash
99gh api repos/{owner}/{repo}/pulls/{number}/reviews --method POST --input /tmp/pr-review-payload.json
100```
101
102Build the JSON payload with all comments. Each comment needs:
103- `path`: file path relative to repo root
104- `line`: the line number in the diff (use the **new file** line number for added/modified lines)
105- `side`: `"RIGHT"` for comments on the new version of the code
106- `body`: the review comment text with tag, issue description, and suggestion. Always append `\n\n---\n_[Generated by AI]_` at the end of every comment body
107
108### Building the review payload
109
110Construct a temporary JSON file with the review data:
111
112```json
113{
114 "event": "COMMENT",
115 "body": "Review summary — found N issues across M files.",
116 "comments": [
117 {
118 "path": "src/auth.ts",
119 "line": 45,
120 "side": "RIGHT",
121 "body": "🔴 **Critical**: Missing null check on `user` before accessing `.id`. This will throw if the query returns no results.\n\n**Suggestion**:\n```ts\nif (!user) {\n throw new NotFoundError('User not found');\n}\n```\n\n---\n_[Generated by AI]_"
122 }
123 ]
124}
125```
126
127Submit with:
128```bash
129gh api repos/{owner}/{repo}/pulls/{number}/reviews --method POST --input /tmp/pr-review-payload.json
130```
131
132Clean up the temp file after submission.
133
134### Line number mapping
135
136- For comments on **added or modified lines**: use the line number from the new file (`+` side of the diff), set `side: "RIGHT"`.
137- For comments on **deleted lines**: use the line number from the old file (`-` side of the diff), set `side: "LEFT"`.
138- To find the correct line number, parse the diff hunk headers (`@@ -old_start,old_count +new_start,new_count @@`) and count lines from there.
139
140## Step 6: Confirmation
141
142After successful submission:
143
144```md
145## Review Submitted
146
147PR #<number> — <title>
148URL: <review URL>
149
150Posted <N> inline comments across <M> files.
151```
152
153If submission fails, show the error and suggest the user check their `gh` auth permissions.