PR Review (Backend, GitHub CLI)

Overview

Review backend pull requests end-to-end using local code analysis and GitHub CLI API calls. Report only actionable, high-signal findings.

Tool Constraints

• Use only: SemanticSearch, WebSearch, Grep, LS, Glob, Read, Shell, GitHub CLI.
• Before any gh command, source the read-only environment script to enable security enforcement:
  bashCopy

  source "<SKILL_DIR>/scripts/activate-gh-readonly.sh"
  

  Replace <SKILL_DIR> with the absolute path to this skill directory.
• After sourcing, use gh commands directly—they are intercepted by the read-only wrapper.
• Verify CLI auth first with gh auth status. If not authenticated, ask the user to run gh auth login.
• Enforce strict read-only mode at all times.
• Never attempt any write operation, including comments, reviews, edits, assignments, merges, closes, reopens, or API mutations.
• If a requested command is blocked by the wrapper, do not try alternatives that can mutate state.
• The read-only wrapper blocks command gh and other bypass attempts.

Workflow

1. Enable read-only environment.
   • Source the environment script: source "<SKILL_DIR>/scripts/activate-gh-readonly.sh"
   • All subsequent gh commands in this shell session are now protected.
2. Prepare review context.
   • Confirm identity and auth: gh auth status, gh api user.
   • Resolve repository owner/name from the current repo or pass -R <OWNER>/<REPO>.
3. Resolve the target PR.
   • Use gh pr view <PR_NUMBER> [--json <fields>] when PR number is known.
   • Otherwise shortlist with gh pr list [flags] and pick the target PR.
4. Sync local repository to the latest PR branch code.
   • Fetch the latest remote state for the PR head branch before reviewing code.
   • Example flow:
     • Get head branch name from PR metadata (headRefName).
     • Run git fetch --prune origin <HEAD_BRANCH>.
     • Review files from FETCH_HEAD or check out a local review branch from it.
5. Gather full PR evidence before judging.
   • Metadata: gh pr view <PR_NUMBER> [--json <fields>]
   • Diff: gh pr diff <PR_NUMBER> [--patch|--name-only]
   • Changed files: gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/files --paginate
   • Reviews: gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/reviews --paginate
   • Checks: gh pr checks <PR_NUMBER> [--json <fields>]
   • Comments:
     • gh pr view <PR_NUMBER> --comments
     • gh api repos/<OWNER>/<REPO>/issues/<PR_NUMBER>/comments --paginate
     • gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments --paginate
6. Inspect changed backend code deeply.
   • Read all high-risk touched files locally (Read, Grep) and correlate with diff hunks.
   • Prioritize request handlers/controllers, business services, authorization logic, database queries, migrations, background jobs, and queue/event handlers.
   • Verify idempotency, transaction safety, concurrency behavior, retry behavior, and backward compatibility for public API contracts.
   • Use gh api repos/<OWNER>/<REPO>/contents/<PATH>?ref=<REF> when exact remote content is needed (content is usually base64 in .content).
7. Apply review checklist with risk-first ordering.
   • Use references/review-checklist.md.
   • Cover security, correctness, data integrity, API compatibility, performance, and test sufficiency before style concerns.
8. Produce actionable review output.
   • Report only issues that are likely defects, regressions, or maintainability risks.
   • Include exact file:line, impact, and concrete fix guidance.
   • End with residual risk and missing validation/testing assumptions.
   • Return findings in chat only; do not write any comment or review back to GitHub.

Response Format

Use this section order:

1. Critical Issues (Must Fix)
2. Important Issues (Should Fix)
3. Suggestions (Consider)
4. Good Practices Noted

For each issue, use:

Issue: <brief description>
Location: <file:line>
Severity: <Critical|High|Medium|Low>
Problematic Code: <snippet or precise behavior>
Suggestion: <specific fix>
Example: <optional patch-style snippet>

GitHub CLI API Equivalents

Use command mappings in references/github-cli-map.md.

Review Tone

• Be constructive and specific.
• Explain impact and rationale.
• Assume positive intent.
• Prefer concise, high-confidence feedback.