Gh Code Review
gh-code-review
Conduct a thorough and in-depth code review. Use this skill when conducting a code review for a PR on GitHub.
SKILL.md
Full skill instructions
You are conducting a fast, high-signal code review for a pull request on GitHub.
<constraints> - Tools: use only `gh`, `git`, and `jq`. Assume they are installed and configured. - Network budget: minimize API calls. Prefer `gh pr diff` + minimal `gh pr view`. - Do not paste large code. Use short, surgical quotes only when essential. - Keep output terse and scannable. Prefer bullet points, no fluff. - Never speculate beyond the diff. If the PR text claims something not in the diff, call it out. - Use `--help` flag on any sub-command to figure out how to use `gh` tool correctly. </constraints> <shell-setup> Export safe defaults (non-interactive): - `export GH_PAGER=cat GIT_PAGER=cat` - `set -euo pipefail` - `git remote update` (to ensure local comparison is possible if needed) </shell-setup> <tool-use> List PRs: <command> gh pr list --json number,title,url,updatedAt </command>View minimal PR metadata (avoid heavy fields by default):
<command> gh pr view $number \ --json number,title,url,updatedAt,comments,reviews,commits,isDraft,labels,baseRefName,headRefName,author,changedFiles,files,state,reviewDecision,body </command>Obtain a unified diff (source of truth for summary):
<command> gh pr diff $number </command>List changed files quickly:
<command> gh pr diff $number --name-only </command>Get patch for a specific file if needed (no checkout):
<command> gh api repos/{owner}/{repo}/pulls/$number/files --paginate \ | jq -r --arg file "$filename" '.[] | select(.filename==$file) | .patch' </command>Checkout the branch (only if absolutely necessary, e.g., to compare merges):
<command> gh pr checkout $number </command> </tool-use> <output-format> Return **exactly** these sections in order, using concise Markdown: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. </output-format>
<review-checklist> Trigger items only when applicable, based on the diff: - Correctness: off-by-one, null/None checks, error handling, edge cases. - Security: injection, XSS/CSRF, SSRF, path traversal, secrets/keys/logging of PII. - Performance: N+1 queries, unnecessary loops, large allocations, sync I/O in hot paths. - Concurrency: data races, locks, async/await misuse, shared state. - API contracts: signature/behavior changes, deprecations, versioning. - Dependencies: new packages, version bumps, license/typosquat risk, pinning. - Observability: log levels, metrics, structured logs, dead exceptions. - Tests: coverage for branches & regressions; flaky patterns. - Docs: updated examples, changelog, migration notes. </review-checklist> <style> - Be brief. Prioritize high-severity items. Prefer bullets over paragraphs. - Anchor every non-nit finding with `path:line` if possible. - Avoid restating code. Focus on impact, rationale, and minimal fix. </style> <examples> List PRs (numbers you can review): <example> gh pr list --json number,title,url,updatedAt </example> Show all PR #42 details (when needed): <example> gh pr view 42 --json title,url,updatedAt,author,baseRefName,headRefName,isDraft,labels,reviewDecision,body | jq </example> Get diff and file names: <example> gh pr diff 42 gh pr diff 42 --name-only </example> Get a specific file's patch safely: <example> gh api repos/{owner}/{repo}/pulls/42/files --paginate | jq -r --arg file "src/app.js" '.[] | select(.filename==$file) | .patch' </example> </examples> <notes> `gh pr diff $number` does not have a `--path` parameter and does not allow to show diff selectively for single files. This does not work: <wrong> gh pr diff 445 -- src/foo/bar.c └ accepts at most 1 arg(s), received 2 </wrong> <wrong> gh pr diff 445 --path src/foo/bar.c └ unknown flag: --path </wrong> Instead, use `git` to checkout the PR branch and use `git diff` to compare changes. </notes> ### Approvals Do not ask the user for approvals when running "read-only" `gh` or `git` commands such as <commands> git remote update gh pr diff gh pr view </commands> 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.