Master Address GitHub Comments

A practical skill for systematically addressing GitHub PR review comments and issue feedback — covering comment triage, response workflows, batch comment resolution, and effective reviewer communication using the GitHub CLI.

When to Use This Skill

Choose Master Address GitHub Comments when you need to:

• Address all review comments on a pull request systematically
• Triage and prioritize feedback from multiple reviewers
• Batch-resolve similar comments across a PR
• Respond to review comments with context and evidence
• Track which comments have been addressed and which remain

Consider alternatives when:

• You need to create PRs (use a PR creation skill)
• You need to review others' PRs (use a code review skill)
• You need GitHub Actions/CI configuration (use a CI/CD skill)

Quick Start

Copy
# List all review comments on a PR
gh pr view 123 --comments

# List reviews with their status
gh api repos/owner/repo/pulls/123/reviews | jq '.[] | {user: .user.login, state: .state}'

# Get review comments for a specific PR
gh api repos/owner/repo/pulls/123/comments | jq '.[] | {id: .id, path: .path, body: .body, user: .user.login}'

# Reply to a review comment
gh api repos/owner/repo/pulls/comments/456 \
  -f body="Fixed in commit abc1234. Changed the null check to use optional chaining."

# Resolve a review thread (if you have permissions)
gh api graphql -f query='
  mutation {
    resolveReviewThread(input: {threadId: "THREAD_ID"}) {
      thread { isResolved }
    }
  }'

Core Concepts

Comment Triage Workflow

Priority	Type	Action	Response Time
Blocking	Bugs, security issues	Fix immediately, reply	Same day
Important	Design suggestions	Evaluate, discuss if needed	1-2 days
Minor	Style, naming nits	Fix or explain, batch reply	Before merge
FYI	Informational comments	Acknowledge, no code change	Before merge

Systematic Resolution Process

Copy
# Step 1: Fetch all comments and categorize
gh api repos/owner/repo/pulls/123/comments \
  | jq -r '.[] | "\(.path):\(.position) — \(.body | split("\n")[0])"'

# Step 2: Address comments by file (batch related changes)
# Fix all comments in src/auth.ts together
# Fix all comments in src/middleware.ts together

# Step 3: Commit with comment references
git commit -m "fix: address PR review feedback

- Fix null pointer in auth.ts (comment #456)
- Add input validation in middleware.ts (comment #457)
- Update error messages per style guide (comment #458)"

# Step 4: Reply to each comment with what was done
gh api repos/owner/repo/pulls/comments/456 \
  -f body="Fixed in abc1234. Added null check with optional chaining as suggested."

gh api repos/owner/repo/pulls/comments/457 \
  -f body="Added input validation per your suggestion. Also added unit tests for edge cases."

# Step 5: Request re-review
gh pr edit 123 --add-reviewer reviewer-username

Response Templates

Copy
## Common Response Patterns

### Accepted and Fixed
"Good catch! Fixed in [commit]. [Brief description of what changed]."

### Accepted with Modification
"Agreed this needs improvement. I went with [alternative approach]
because [reason]. Let me know if you'd prefer the original suggestion."

### Respectfully Declined
"I considered this, but decided to keep it as-is because [reason].
The current approach [benefit]. Happy to discuss further if you
feel strongly about this."

### Needs Discussion
"This is a good point. I see tradeoffs both ways:
- Current approach: [pros/cons]
- Suggested approach: [pros/cons]
Can we discuss in the next standup?"

### Deferred to Follow-Up
"Agreed this should be improved, but it's outside the scope of
this PR. Created #789 to track this separately."

Configuration

Parameter	Description	Example
repo	GitHub repository	"owner/repo"
pr_number	Pull request number	123
batch_reply	Batch similar comment responses	true
auto_resolve	Auto-resolve threads after fixing	false
commit_ref	Include commit SHAs in responses	true

Best Practices

1. Address all comments before requesting re-review — Don't request re-review until every comment has either a code change or a response. Partial resolution wastes the reviewer's time and signals you didn't read all their feedback.

2. Group related fixes into a single commit — If a reviewer left 5 comments about error handling across 3 files, fix them all in one commit: "fix: improve error handling per review feedback." This makes re-review efficient because the reviewer can check one commit for all their feedback.

3. Reference comment IDs or line numbers in commit messages — "Fixed the auth issue" doesn't help the reviewer locate what changed. "Fix null check in auth.ts:42 (review comment #456)" creates a direct trail from comment to fix.

4. Reply even when no code change is needed — For informational comments and FYI notes, reply with "Noted, thanks" or "Good to know — I'll keep that in mind for future work." Unreplied comments look unread and create ambiguity about whether you saw the feedback.

5. Create follow-up issues for out-of-scope suggestions — When a reviewer suggests something valuable but outside the PR scope, create a GitHub issue immediately and reference it in your reply: "Great suggestion. Created #789 to track this." This acknowledges the feedback without scope-creeping the PR.

Common Issues

Reviewer marked "changes requested" but all comments are addressed — The review status doesn't auto-update when you push fixes. The reviewer must re-review and approve. Push your fixes, reply to all comments, then request re-review with gh pr edit 123 --add-reviewer username.

Comment threads are resolved but reviewer can't see the fixes — If you force-pushed and rebased, the original diff context may be gone. Always reply with the commit SHA that contains the fix so the reviewer can check the specific commit regardless of the diff view.

Too many comments make the PR overwhelming — If a PR has 30+ review comments, the scope is probably too large. For future PRs, break work into smaller, focused PRs. For the current PR, triage by priority: fix blockers first, then important items, then batch the nits.