PR Review Response

Evaluate and respond to PR review comments critically rather than accepting them blindly.

Usage

Invoke with a PR number or let it auto-detect from the current branch:

/pr-review-response 42
/pr-review-response

Or trigger naturally: “respond to PR review comments”, “handle the review feedback on my PR”, “address the bot comments on PR #42”.

Workflow

1. Identify the PR

# If PR number given as argument, use it. Otherwise detect from branch:
BRANCH=$(git branch --show-current)
PR_NUMBER=$(gh pr list --head "$BRANCH" --json number --jq '.[0].number')
REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')

If no open PR is found, tell the user and stop.

2. Fetch all review comments

gh api "repos/${REPO}/pulls/${PR_NUMBER}/comments" --paginate

Also fetch PR review bodies (top-level review summaries):

gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" --paginate

Parse each comment to extract:

• id – comment ID for replying
• path – file path
• line / original_line – line number in diff
• body – the comment text
• diff_hunk – surrounding diff context
• user.login – who left it (bot vs human)
• in_reply_to_id – thread parent (skip if already replied to)

3. Read full context

For each commented file, read the entire file — not just the diff hunk. Bots only see the diff; you see the whole project.

Also read these if they exist:

• AGENTS.md or CLAUDE.md — project conventions
• README.md — project intent
• Adjacent files that inform the decision (imports, types, configs)

4. Evaluate each comment

For every comment, decide one of three outcomes:

Accept

The suggestion is correct and improves the code. Criteria:

• Fixes a real bug or correctness issue
• Aligns with project conventions (check AGENTS.md/existing patterns)
• The proposed fix is actually better than what’s there

Decline

The suggestion is wrong, irrelevant, or conflicts with project intent. Common reasons:

• Bot lacks project context (e.g., suggesting strict TS options when intentionally relaxed)
• Suggestion conflicts with AGENTS.md or established patterns
• It’s a stylistic preference, not a correctness issue
• The bot misunderstands the architecture or tooling
• The “fix” would break something the bot can’t see

Discuss

You’re unsure, or the comment raises a legitimate question that needs the user’s input.

5. Present assessment for approval

Before making ANY changes, show the user a summary table:

PR #42 — 3 review comments from gemini-code-assist[bot]

| # | File             | Comment (summary)              | Verdict | Reason                                    |
|---|------------------|--------------------------------|---------|-------------------------------------------|
| 1 | package.json     | module field wrong path        | ACCEPT  | Genuine bug — entry point is src/index.ts  |
| 2 | tsconfig.json    | Enable noUnusedLocals/Params   | DECLINE | Intentionally relaxed for development      |
| 3 | .gitignore       | Commit bun.lock                | ACCEPT  | Correct — lockfiles should be committed    |

Planned actions:
- Fix package.json module field
- Fix .gitignore to stop ignoring bun.lock
- Commit and push changes
- Post PR comment with responses to all 3 comments

Proceed? (changes will be committed and pushed)

Wait for user approval. Do not proceed without it.

6. Apply changes

On approval:

1. Apply accepted fixes — edit the files as needed
2. Stage and commit with a clear message:

   git add -A && git commit -m "address PR review: accept N, decline M comments"
   

3. Push to the PR branch:

   git push
   

7. Post PR responses

Compose a single PR comment that addresses every review comment. Format:

BODY=$(cat <<'COMMENT'
## Review Response

### package.json — module field path ✅
Accepted. Fixed `module` from `index.ts` to `src/index.ts`. Good catch — the entry point was incorrect.

### tsconfig.json — strict unused checks ❌
Declined. `noUnusedLocals` and `noUnusedParameters` are intentionally disabled. During active development, unused variables are common as code evolves. This is a deliberate choice documented in project conventions, not an oversight.

### .gitignore — commit bun.lock ✅
Accepted. Removed `bun.lock` from `.gitignore`. Lockfiles should be committed for reproducible builds.

---
*2 accepted, 1 declined*
COMMENT
)

gh pr comment "$PR_NUMBER" --body "$BODY"

Use reply threads where possible — reply to individual comments:

# Reply to a specific review comment
gh api "repos/${REPO}/pulls/${PR_NUMBER}/comments/${COMMENT_ID}/replies" \
  -f body="Accepted. Fixed in latest push — changed module field to \`src/index.ts\`."

Key Principles

1. Never blindly accept — bots lack project context. A suggestion that looks reasonable in isolation may conflict with project intent.
2. Read the full file — don’t evaluate based on the diff hunk alone. The surrounding code matters.
3. Check conventions first — AGENTS.md, CLAUDE.md, and existing patterns take precedence over generic best practices.
4. Explain declines — a declined suggestion deserves a clear reason. This helps the reviewer (human or bot) and documents the decision.
5. Batch everything — one commit for all fixes, one comment for all responses. Don’t create noise with per-comment commits.
6. User approval gate — never push code or post comments without explicit user approval.

Watch Mode

After pushing a PR, you can use the watch script to automatically respond once a review comes in:

./skills/pr-review-response/scripts/watch-pr.sh 42
# or auto-detect:
./skills/pr-review-response/scripts/watch-pr.sh

This polls for new comments, waits for the review to stabilize (60s cooldown), then invokes this skill. See scripts/watch-pr.sh for details.