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:

bash

# 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:

•Read the relevant file
•Apply the fix
•Note the change made

Step 4: Commit and Push

bash

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:

code

✅ Addressed - [brief description of fix]

Skipped format:

code

🔁 Skipped - [reason]

Create a batch file and post replies:

bash

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:

bash

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

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