Address PR Review Comments

This skill guides you through addressing PR review comments systematically.

Scripts location: .github/skills/address-pr-comments/

⚠️ Critical: Only Address the LATEST Review from EACH Reviewer

Address only the MOST RECENT review from each reviewer. If there are 3 reviewers (e.g., an automated reviewer, human reviewer A, human reviewer B), you address 3 reviews — the latest one from each.

Do NOT address:

• Earlier reviews from the same reviewer (even if threads appear "unresolved")
• "Duplicate comments" sections (these reference old unfixed issues — they'll be re-raised in new reviews if still relevant)
• Threads opened in previous reviews that weren't part of a reviewer's latest review

Why? Earlier reviews may contain:

• Feedback that was already addressed
• Suggestions the reviewer reconsidered
• Issues that are no longer relevant after code changes

The pr-review-summaries.js script automatically filters to show only the most recent review per author. Trust this output and ignore older feedback.

Workflow

Step 1: Gather PR Comments

Run the review summaries script to get the latest feedback:

# Get the LATEST review summary from each reviewer (automated tools and humans)
# Earlier reviews are ignored - only the most recent per author is returned
node .github/skills/address-pr-comments/pr-review-summaries.js --json > /tmp/pr-summaries.json

What to address from the review summary:

• ✅ "Actionable comments" — these are the main issues to fix
• 🔁 "Nitpick comments" — optional improvements, skip with reason if not addressing
• ❌ "Duplicate comments" — DO NOT address these; they're references to older unfixed issues

Step 2: Analyze and Categorize

Parse the review summary JSON and categorize the actionable comments only:

Categories:

• Address: Valid issues that should be fixed
• Skip: Issues that are intentional, already fixed, or not applicable

Skip Reasons:

• Intentional design decision
• Already addressed in another commit
• False positive from automated reviewer
• Outside scope of this PR
• Breaking change that needs separate PR

Do NOT include in your analysis:

• "Duplicate comments" — these are old issues, not new feedback
• Unresolved threads from previous reviews

Step 3: Make Changes

For each item to address:

1. Read the relevant file
2. Apply the fix
3. Note the change made

Step 4: Commit and Push

git add -A
git commit -m "fix: address PR review comments

- Item 1 description
- Item 2 description
..."
git push

Step 5: Reply to Thread Comments (Optional)

If the review summary JSON includes unresolvedThreads from the latest review, reply to those threads:

Addressed format:

✅ Addressed - [brief description of fix]

Skipped format:

🔁 Skipped - [reason]

Create a batch file and post replies:

cat > /tmp/replies.json << 'EOF'
{
  "threadReplies": [
    { "threadId": "PRRT_xxx", "message": "✅ Addressed - awaited refetch and moved setRefreshing to finally block" },
    { "threadId": "PRRT_yyy", "message": "🔁 Skipped - intentional design: we want immediate feedback" }
  ],
  "prComment": null
}
EOF

node .github/skills/address-pr-comments/pr-reply.js --batch /tmp/replies.json

Note: Only reply to threads listed in unresolvedThreads from the review summary output. Do NOT use pr-comments.js separately — it may return threads from older reviews.

Step 6: Post Summary Comment

Post a summary comment covering only the latest review's actionable comments and nitpicks:

node .github/skills/address-pr-comments/pr-reply.js --pr-comment --message "## PR Review Response

### ✅ Addressed
- [list of addressed items with file:line references]

### 🔁 Skipped
- [list of skipped items with reasons]

### 📋 Notes
- [any additional context]
"

Important Notes

1. Only the LATEST review matters: Ignore "duplicate comments", unresolved threads from old reviews, and any feedback not in the most recent review summary
2. Thread IDs: Use the id field from thread objects (format: PRRT_...)
3. Review Summaries: These don't have thread IDs, so they can only be addressed in the final summary comment
4. Keep replies brief: One line for addressed items, one line + reason for skipped
5. Batch operations: Always use --dry-run first to verify before posting