Github Review Pr

Use when a PR needs full review — fixes CI failures first, then addresses unresolved review comments. Run failures first because…

getzazu updated 2mo ago
Claude CodeGeneric
View source ↗
---
description: "Use when a PR needs full review — fixes CI failures first, then addresses unresolved review comments. Run failures first because comment fixes trigger new CI runs that obscure the original failures."
model: claude-opus-4-7
argument-hint: "PR number (e.g., 1690 or #1690)"
allowed-tools: Bash(gh pr list:*), Bash(gh pr view:*), Bash(gh pr checks:*), Bash(gh pr diff:*), Bash(gh pr comment:*), Bash(gh api:*), Bash(gh run view:*), Bash(git log:*), Bash(git blame:*), Bash(git diff:*), Bash(git push:*), Bash(git commit:*), Bash(git add:*), Bash(bun:*), Bash(./dist/zazu:*), Read, Write, Edit, Glob, Grep, Agent
---

# Review GitHub PR (full pass): $ARGUMENTS

Run a full review pass in two phases, in this order:

1. **Phase A: CI failures** — fix anything red before touching review comments.
2. **Phase B: Unresolved review comments** — evaluate, fix valid ones, push back on incorrect suggestions, resolve all threads.

Reverse order is wrong: comment fixes push new commits that retrigger CI, masking the original failure signal.

## Phase 0: Determine the PR

If `$ARGUMENTS` is a number → that PR. If it's `#N` → strip the `#`. If empty → use the current branch's PR (`gh pr view --json number`).

## Phase A: CI failures

```bash
gh pr checks <PR>

For each failing check:

  1. gh run view <run-id> --log-failed — get the actual error
  2. Reproduce locally:
    • Test failure → bun test test/cli.test.js
    • Lint failure → bun run lint
    • Typecheck failure → bun run typecheck
    • Bundle failure → bun run check
    • Cross-compile failure → bun run build
  3. Fix the root cause. Don't:
    • Disable the failing test
    • Add a // biome-ignore to silence the linter
    • Cast types to bypass the typechecker
  4. Verify locally: bun run check:all
  5. Commit with conventional-commit prefix (fix:, test:, chore:)
  6. Push: git push origin <branch>
  7. Wait for the new run: gh pr checks <PR> --watch

Repeat until all checks are green.

Phase B: Unresolved review comments

The REST endpoint pulls/<N>/comments returns every review comment with no resolution state. We want only unresolved threads — use GraphQL's reviewThreads.isResolved:

gh api graphql -f query='
query($owner: String!, $repo: String!, $number: Int!) {
  repository(owner: $owner, name: $repo) {
    pullRequest(number: $number) {
      reviewThreads(first: 100) {
        nodes {
          id
          isResolved
          path
          line
          comments(first: 1) {
            nodes {
              databaseId
              author { login }
              body
            }
          }
        }
      }
    }
  }
}' -F owner=<owner> -F repo=<repo> -F number=<PR> \
  --jq '.data.repository.pullRequest.reviewThreads.nodes | map(select(.isResolved == false)) | map({thread_id: .id, comment_id: .comments.nodes[0].databaseId, path, line, author: .comments.nodes[0].author.login, body: (.comments.nodes[0].body | .[:300])})'

The thread_id (GraphQL node id, looks like PRRT_…) is what you need to mark a thread resolved later. The comment_id (numeric databaseId) is what the REST pulls/comments/<id>/replies endpoint expects when posting a reply.

For each unresolved thread:

  1. Read the actual code at the cited line — don't assume the comment is current. Codebase may have moved on.

  2. Evaluate against project conventions in CLAUDE.md. If the suggestion conflicts with documented conventions, push back.

  3. Decide: valid issue → fix. Invalid suggestion → reply with reasoning. Already addressed → reply with the commit sha.

  4. Implement valid fixes minimally:

    • Touch only the cited line(s) plus what the fix requires
    • Don't rewrite adjacent code
    • Match existing style
  5. Reply on the comment thread (not as a new top-level comment):

    gh api repos/{owner}/{repo}/pulls/<PR>/comments/<comment_id>/replies \
      -f body='<reply>'
    

    Optionally mark the thread resolved when the work is committed:

    gh api graphql -f query='
    mutation($id: ID!) {
      resolveReviewThread(input: { threadId: $id }) {
        thread { isResolved }
      }
    }' -F id=<thread_id>
    
  6. Verify after each batch of fixes: bun run check:all

  7. Commit + push in batches grouped by topic (one commit per CodeRabbit theme is fine).

Order of comment batches

Evaluate findings in this order so cheap fixes ship first:

  1. Real bugs — wrong behavior, missing edge case, security issue. Fix immediately.
  2. Type-safety issues — Biome correctness rules, unhandled error paths.
  3. Style / lint — only fix if Biome doesn't auto-fix.
  4. Suggestions / nits — accept if the author has earned trust; push back if it adds complexity for no gain.

Reply templates

Accepted + fixed:

Fixed in <sha>. .

Pushed back:

Disagree — . . Leaving as-is.

Already addressed:

Already handled in <sha> (earlier in this PR / on main).

Final verification

gh pr checks <PR>            # all green
gh pr view <PR> --json reviewDecision

If reviewDecision is CHANGES_REQUESTED, ask the reviewer to re-review.

Karpathy guidelines

Apply always. Specifically here:

  • Surgical changes — only touch what the comment cites.
  • Surface tradeoffs — if the reviewer's suggestion has a downside, name it before applying.

Maintain Github Review Pr?

Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.

[Github Review Pr on getagentictools](https://getagentictools.com/loops/getzazu-cli-github-review-pr?ref=badge)
npx agentictools info loops/getzazu-cli-github-review-pr

The second line is the CLI lookup for this page — handy in READMEs and docs.