review-pr-comments.md

Review PR Comments

Review and address PR comments with code suggestions on the current branch.

Instructions

You are a PR comment reviewer that helps address feedback on pull requests. Follow these steps:

Step 1: Find PR for Current Branch

First, get the current branch name and check for associated PRs:

# Get current branch
git branch --show-current

# List PRs for this branch
gh pr list --head $(git branch --show-current) --json number,title,state,url

If no PR found: Inform the user that no PR exists for the current branch and ask if they want to create one.

If multiple PRs found: Present the list to the user and ask which PR they want to review using AskUserQuestion tool.

If exactly one PR: Proceed with that PR.

Step 2: Fetch PR Comments with Code Suggestions

Get all review comments on the PR:

# Get PR number from step 1, then fetch comments
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --jq '.[] | {id: .id, path: .path, line: .line, body: .body, user: .user.login, diff_hunk: .diff_hunk, in_reply_to_id: .in_reply_to_id}'

Also fetch the PR review threads to understand the conversation context:

gh pr view {pr_number} --json reviewDecision,reviews,comments

Step 3: Get PR Diff and Changelog

Fetch the PR diff to understand the full context of changes:

gh pr diff {pr_number}

Check if a changelog file exists in the diff:

gh pr diff {pr_number} --name-only | grep -i changelog

If no changelog found in the diff:

• Warn the user that no changelog entry was detected
• Check the changelog/ directory for existing entries to determine the next number
• Suggest creating a changelog entry following the format in changelog/template.md

Step 4: Analyze Each Comment

For each comment with a code suggestion, analyze:

1. Read the relevant file to understand the full context (not just the diff hunk)

2. Evaluate the suggestion's viability:

   • Is it technically correct?
   • Does it align with the codebase patterns (check CLAUDE.md conventions)?
   • Does it improve code quality, performance, or readability?
   • Is it necessary or just a stylistic preference?
   • Could it introduce bugs or break existing functionality?

3. Categorize each suggestion:

   • APPLY: Valid improvement that should be implemented
   • PARTIALLY APPLY: Good idea but needs modification
   • DISCUSS: Needs clarification or has trade-offs worth discussing
   • DECLINE: Not appropriate for valid technical reasons

Step 5: Present Recommendations to User

For each comment, present:

1. Comment Summary: Who said what, on which file/line
2. Your Analysis: Technical assessment of the suggestion
3. Recommendation: APPLY / PARTIALLY APPLY / DISCUSS / DECLINE
4. Proposed Code Change (if applicable): The exact change to make
5. Proposed Reply: A professional response to the comment explaining:
   • For APPLY: "Good catch! Applied this change."
   • For PARTIALLY APPLY: "Thanks for the suggestion! I've implemented a modified version that [explanation]."
   • For DISCUSS: "Thanks for raising this. [Your question or concern about the trade-offs]."
   • For DECLINE: "Thanks for the review. I've kept the current approach because [technical reason]."

Step 6: Apply Changes (with user confirmation)

After presenting all recommendations:

1. Ask the user which changes they want to apply using AskUserQuestion
2. For approved changes:
   • Use the Edit tool to make the code changes
   • Run pnpm typecheck to verify no type errors were introduced
   • Run pnpm check to ensure linting passes

Step 7: Reply to Comments

For each processed comment, post the reply:

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies -f body="[reply text]"

Step 8: Resolve All Conversations

After replying to all comments, resolve the review threads:

1. First, fetch all review thread IDs:

gh api graphql -f query='
query {
  repository(owner: "{owner}", name: "{repo}") {
    pullRequest(number: {pr_number}) {
      reviewThreads(first: 50) {
        nodes {
          id
          isResolved
        }
      }
    }
  }
}'

2. For each unresolved thread, resolve it:

gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "{thread_id}"}) { thread { isResolved } } }'

Note: Run the resolve mutation for each thread ID returned from the query. Multiple resolve calls can be run in parallel for efficiency.

Step 9: Commit Changes (if any)

If any code changes were made:

1. Show the user what files were modified
2. Ask if they want to commit the changes
3. If yes, create a commit with message: "Address PR review feedback"
4. Ask if they want to push the changes

Important Guidelines

• Always read the full file context, not just the diff hunk
• Reference CLAUDE.md conventions when evaluating suggestions
• Be professional and constructive in all proposed replies
• Never dismiss valid feedback - if declining, always provide a clear technical reason
• If a suggestion conflicts with project conventions, cite CLAUDE.md
• Check for changelog entries and remind the user if missing
• Always run typecheck and lint before finalizing changes