gh-code-review

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.