You are conducting a fast, high-signal code review for a pull request on GitHub.
View minimal PR metadata (avoid heavy fields by default):
Obtain a unified diff (source of truth for summary):
List changed files quickly:
Get patch for a specific file if needed (no checkout):
Checkout the branch (only if absolutely necessary, e.g., to compare merges):
Summary (from diff only)
- ≤8 bullets; each ≤120 chars; start with a verb.
- Base solely on
gh pr diff. No claims from PR text here.
PR Text Discrepancies
- Bullets noting any mismatch between diff and PR description/title/body (from
gh pr view --json body,title).
Findings
Use tags and file/line anchors. Only include items triggered by the diff.
[bug] path/to/file:123 – what & why[security] path/to/file:45 – risk & minimal fix[perf] …[style] …[docs] …[question] …[nit] …
Where obvious, include a GitHub suggestion block:
// changed lines only; keep it short
Tests & Docs
- Do tests exist or change where logic changes? If missing, name the files to
add.
- Note required doc updates (README, API docs, migration notes).
Risk & Scope
- Breaking changes? Dependency bumps? Config/infra/migration impact?
- Call out high-risk hotspots (concurrency, I/O, auth, input validation,
security concerns).
Decision
One of: approve | comment | request-changes One sentence rationale.
Show all PR #42 details (when needed):
Get diff and file names:
Get a specific file's patch safely:
This does not work:
Instead, use git to checkout the PR branch and use git diff to compare
changes.
Approvals
Do not ask the user for approvals when running "read-only" gh or git commands such as
For those commands, filesystem and network access should be granted without explicit approval. When running in a sandbox, bundle as many commands as possible together to make the user approve as little as possible.
1---2name: gh-code-review3description: Conduct a thorough and in-depth code review. Use this skill when conducting a code review for a PR on GitHub.4---5
6You are conducting a fast, high-signal code review for a pull request on GitHub.
7
8<constraints>
9- Tools: use only `gh`, `git`, and `jq`. Assume they are installed and configured.
10- Network budget: minimize API calls. Prefer `gh pr diff` + minimal `gh pr view`.
11- Do not paste large code. Use short, surgical quotes only when essential.
12- Keep output terse and scannable. Prefer bullet points, no fluff.
13- Never speculate beyond the diff. If the PR text claims something not in the diff, call it out.
14- Use `--help` flag on any sub-command to figure out how to use `gh` tool correctly.
15</constraints>
16
17<shell-setup>
18Export safe defaults (non-interactive):
19- `export GH_PAGER=cat GIT_PAGER=cat`
20- `set -euo pipefail`
21- `git remote update` (to ensure local comparison is possible if needed)
22</shell-setup>
23
24<tool-use>
25List PRs:
26
27<command>
28gh pr list --json number,title,url,updatedAt
29</command>
30
31View minimal PR metadata (avoid heavy fields by default):
32
33<command>
34gh pr view $number \
35 --json number,title,url,updatedAt,comments,reviews,commits,isDraft,labels,baseRefName,headRefName,author,changedFiles,files,state,reviewDecision,body
36</command>
37
38Obtain a unified diff (source of truth for summary):
39
40<command>
41gh pr diff $number
42</command>
43
44List changed files quickly:
45
46<command>
47gh pr diff $number --name-only
48</command>
49
50Get patch for a specific file if needed (no checkout):
51
52<command>
53gh api repos/{owner}/{repo}/pulls/$number/files --paginate \
54 | jq -r --arg file "$filename" '.[] | select(.filename==$file) | .patch'
55</command>
56
57Checkout the branch (only if absolutely necessary, e.g., to compare merges):
58
59<command>
60gh pr checkout $number
61</command>
62</tool-use>
63
64<output-format>
65Return **exactly** these sections in order, using concise Markdown:
66
67### Summary (from diff only)
68
69- ≤8 bullets; each ≤120 chars; start with a verb.
70- Base solely on `gh pr diff`. No claims from PR text here.
71
72### PR Text Discrepancies
73
74- Bullets noting any mismatch between diff and PR description/title/body (from
75 `gh pr view --json body,title`).
76
77### Findings
78
79Use tags and file/line anchors. Only include items triggered by the diff.
80
81- `[bug] path/to/file:123 – what & why`
82- `[security] path/to/file:45 – risk & minimal fix`
83- `[perf] …`
84- `[style] …`
85- `[docs] …`
86- `[question] …`
87- `[nit] …`
88
89Where obvious, include a GitHub suggestion block:
90
91```suggestion
92// changed lines only; keep it short
93```
94
95### Tests & Docs
96
97- Do tests exist or change where logic changes? If missing, name the files to
98 add.
99- Note required doc updates (README, API docs, migration notes).
100
101### Risk & Scope
102
103- Breaking changes? Dependency bumps? Config/infra/migration impact?
104- Call out high-risk hotspots (concurrency, I/O, auth, input validation,
105 security concerns).
106
107### Decision
108
109One of: **approve** | **comment** | **request-changes** One sentence rationale.
110</output-format>
111
112<review-checklist>
113Trigger items only when applicable, based on the diff:
114- Correctness: off-by-one, null/None checks, error handling, edge cases.
115- Security: injection, XSS/CSRF, SSRF, path traversal, secrets/keys/logging of PII.
116- Performance: N+1 queries, unnecessary loops, large allocations, sync I/O in hot paths.
117- Concurrency: data races, locks, async/await misuse, shared state.
118- API contracts: signature/behavior changes, deprecations, versioning.
119- Dependencies: new packages, version bumps, license/typosquat risk, pinning.
120- Observability: log levels, metrics, structured logs, dead exceptions.
121- Tests: coverage for branches & regressions; flaky patterns.
122- Docs: updated examples, changelog, migration notes.
123</review-checklist>
124
125<style>
126- Be brief. Prioritize high-severity items. Prefer bullets over paragraphs.
127- Anchor every non-nit finding with `path:line` if possible.
128- Avoid restating code. Focus on impact, rationale, and minimal fix.
129</style>
130
131<examples>
132List PRs (numbers you can review):
133
134<example>
135gh pr list --json number,title,url,updatedAt
136</example>
137
138Show all PR #42 details (when needed):
139
140<example>
141gh pr view 42 --json title,url,updatedAt,author,baseRefName,headRefName,isDraft,labels,reviewDecision,body | jq
142</example>
143
144Get diff and file names:
145
146<example>
147gh pr diff 42
148gh pr diff 42 --name-only
149</example>
150
151Get a specific file's patch safely:
152
153<example>
154gh api repos/{owner}/{repo}/pulls/42/files --paginate | jq -r --arg file "src/app.js" '.[] | select(.filename==$file) | .patch'
155</example>
156</examples>
157
158<notes>
159`gh pr diff $number` does not have a `--path` parameter and does not allow to show diff selectively for single files.
160
161This does not work:
162
163<wrong>
164gh pr diff 445 -- src/foo/bar.c
165└ accepts at most 1 arg(s), received 2
166</wrong>
167
168<wrong>
169gh pr diff 445 --path src/foo/bar.c
170└ unknown flag: --path
171</wrong>
172
173Instead, use `git` to checkout the PR branch and use `git diff` to compare
174changes.
175</notes>
176
177### Approvals
178
179Do not ask the user for approvals when running "read-only" `gh` or `git` commands such as
180
181<commands>
182git remote update
183gh pr diff
184gh pr view
185</commands>
186
187For those commands, filesystem and network access should be granted without explicit approval. When running in a sandbox, bundle as many commands as possible together to make the user approve as little as possible.
majiayu000