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:

  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.