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):
<cleanup_rules>
When writing to /tmp, always manage temporary files through an agent-specific tmpdir for easier tracking and cleanup. For script automation:
- Create a agent-unique temp dir:
TEMP_DIR=$(mktemp -d "/tmp/codex-$(date +%F)-XXXXXX"). Use codex-, claude-, gemini- or whatever is applicable here - Immediately set a trap:
trap 'rm -rf "$TEMP_DIR"' EXIT - Store all agent/skill temp files inside
$TEMP_DIR; do not mix with others - Avoid redundant checks: rely on the trap for cleanup. Never leave temp dirs/files behind </cleanup_rules>
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.