abhiroopb/skills/address-pr-comments

Address Pull Request Review Comments

When the user asks you to address PR comments or review feedback, follow this process. Prioritize human review comments over automated/bot comments.

Step 1: Review and Critically Evaluate Comments

Read through the comments to understand what changes are being requested. Before implementing any changes, ask yourself: "What would my tech lead say about this comment?"

Critical Evaluation Guidelines

1. Question the feedback: Not all comments are correct or necessary. Does it improve the code? Are there trade-offs?
2. Bot comments deserve extra scrutiny: Automated review tools can be overly pedantic or miss context.
3. Evaluate consistency vs. correctness: Is the existing code you're matching correct, or is it a bug being perpetuated?

Planning & Human Confirmation

• For simple/straightforward fixes (e.g., variable renaming, typos, null checks): proceed directly.
• For complex or ambiguous changes (e.g., architectural shifts, behavioral changes): list your plan and ask the user for confirmation before proceeding.

Step 2: Make the Requested Changes

For each comment or group of related comments:

1. Read the relevant file and surrounding context.
2. Make the requested change using the Edit tool.
3. Verify changes with a sub-agent for non-trivial changes, refactors, or where correctness isn't immediately obvious.
4. Ensure the change compiles and makes sense.

Step 3: Commit and Push Changes

After addressing all comments, commit and push the changes. One commit per comment or issue. Don't bundle multiple comments or issues into a single commit.

Step 4: Resolve Review Threads

Get Review Thread IDs

To resolve comments, you need the review thread IDs (not the comment IDs). Use GraphQL:

gh api graphql -f query="
query {
  repository(owner: \"${REPO_OWNER}\", name: \"${REPO_NAME}\") {
    pullRequest(number: ${PR_NUMBER}) {
      reviewThreads(first: 100) {
        nodes {
          id
          isResolved
          comments(first: 1) {
            nodes {
              databaseId
              body
            }
          }
        }
      }
    }
  }
}"

This returns thread IDs (format: PRRT_kwDOEv8_B85ev7PY) mapped to comment IDs.

Ask for Confirmation

Before resolving comments, ask the user:

"I've addressed the following PR comments:

1. [Line X in file.go] - Removed unnecessary comment
2. [Line Y in file2.go] - Simplified logic ...

Should I mark these {N} review threads as resolved?"

Resolve Review Threads via GraphQL

If confirmed, resolve all addressed threads using GraphQL mutation:

gh api graphql -f query='
mutation {
  t1: resolveReviewThread(input: {threadId: "PRRT_kwDOEv8_B85ev7PY"}) { thread { id } }
  t2: resolveReviewThread(input: {threadId: "PRRT_kwDOEv8_B85ev7Tz"}) { thread { id } }
  ...
}'

You can batch resolutions in a single mutation for efficiency.

Step 5 (Optional): Reply to PR Comments

Sometimes you may need to reply to a comment to answer a question or provide technical justification for your approach. With the user's permission, you can reply to specific comments.

How to Reply to a Review Comment

Use the REST API with the in_reply_to parameter to post a reply.

gh api -X POST "repos/${REPO_OWNER}/${REPO_NAME}/pulls/${PR_NUMBER}/comments" \
  -f body="Your reply message here" \
  -F in_reply_to={COMMENT_DATABASE_ID}

Reply Signing Requirement

All replies MUST be signed as generated by AI. Use your signature format.

Example Use Cases

• Explaining technical reasoning for your implementation approach
• Answering a question about the changes
• Providing justification for NOT making a requested change
• Asking for clarification on ambiguous feedback

Always ask the user before posting replies - use this sparingly and only when helpful context is needed.

Important Notes

• Thread IDs vs Comment IDs: You must use thread IDs (PRRT_...) for resolving, not comment IDs
• GraphQL Only: The REST API doesn't support resolving threads - you must use GraphQL
• Confirmation: Always ask before resolving to ensure the user agrees changes are complete
• Unresolved Comments: Leave comments unresolved if they require additional work or discussion
• Push First: Ensure changes are committed and pushed before resolving threads