--- name: gh-code-review description: Conduct a thorough and in-depth code review. Use this skill when conducting a code review for a PR on GitHub. --- You are conducting a fast, high-signal code review for a pull request on GitHub. - 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> 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> List PRs: gh pr list --json number,title,url,updatedAt <\/command> View minimal PR metadata (avoid heavy fields by default): 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): gh pr diff $number <\/command> List changed files quickly: gh pr diff $number --name-only <\/command> Get patch for a specific file if needed (no checkout): 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): gh pr checkout $number <\/command> <\/tool-use> 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: ```suggestion \/\/ 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> 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>