GH PR Review
Overview
Perform a structured PR review using gh commands and a consistent checklist. Provide concise findings and questions tailored to the PR scope.
Workflow
Identify the repo and PR number
- Accept a PR URL or explicit
owner/repo+ PR number. - Ask only if missing.
- Accept a PR URL or explicit
Fetch PR metadata
gh pr view <num> --repo owner/repo- Use title/body, labels, reviewers, and stats to frame scope.
Fetch the diff
gh pr diff <num> --repo owner/repo- If diff is large, focus on critical files or API/DB changes first.
Fetch discussion context (optional)
gh pr view <num> --repo owner/repo --commentsgh api repos/owner/repo/pulls/<num>/commentsfor line threads.- Use when the user asks about a specific discussion or rationale.
Apply the standard review checklist
- Purpose/Scope: Confirm intent and changes match the stated goal.
- Correctness: Identify logic errors, edge cases, or state inconsistencies.
- Domain/Model: Check invariants, naming, and aggregate boundaries.
- Data/DB: Validate constraints, NULL rules, FK integrity, migrations.
- API/Compatibility: Confirm request/response changes and version impact.
- Performance: Watch for heavy queries, missing indexes, N+1.
- Ops/Observability: Consider batch timing, retries, logging, metrics.
- Tests: Ensure critical paths are covered; note missing tests.
Respond with a structured review
- Prioritize issues by severity.
- Cite file/line when available; otherwise point to section/topic.
- Ask targeted questions when assumptions are unclear.
- If the user asked for guidance only, do not post comments.
Output Guidance
Follow the platform review style. Keep summaries short and lead with findings. If the PR is a design-doc only, focus on architecture, data model, and risks.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.