Menu
Respond to PR review comments systematically in thread context
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Close a GitHub issue with discipline — resolved, superseded, or duplicate. Pre-flights body + comments, migrates substance before destroying context, cross-links both directions.
File a new GitHub issue with duplicate search, scope decision, label discovery, and preview before posting. Prevents fragmented or silently-filed issues.
Restructure the topology of GitHub issues — split one into many focused replacements, or merge multiple into one keeper. Migrates substance and cross-links before closing anything.
Update an existing GitHub issue — edit body, post a comment, retag, or reopen. Pre-flights body + comments; acknowledges stale framing instead of silently rewriting.
Review and address PR feedback using 6-dimensional code review
Structured code review using 6 dimensions. Works with or without the code-reviewer agent.
| name | pr-comments |
| description | Respond to PR review comments systematically in thread context |
| allowed-tools | Bash(gh api *), Bash(gh pr *), Bash(git *), Bash(${CLAUDE_PLUGIN_ROOT}/skills/pr-comments/reply-to-comment.sh*), Bash(${CLAUDE_PLUGIN_ROOT}/skills/shared/resolve-github-context.sh*), Bash(${CLAUDE_PLUGIN_ROOT}/skills/shared/fetch-pr-context.sh*), Read |
Systematically respond to PR review comments, ensuring all feedback is addressed in thread context.
Reply to every unresolved PR comment with appropriate responses (fixed, already-fixed, or acknowledged).
${CLAUDE_PLUGIN_ROOT}/skills/pr-comments/reply-to-comment.sh {owner}/{repo} {number} {comment_id} 'body'. The script validates the comment belongs to the correct PR before posting. Never use standalone gh pr comment {number} (loses thread context) or raw gh api (easy to get the endpoint wrong).gh CLI and appropriate GitHub accessctx=$(${CLAUDE_PLUGIN_ROOT}/skills/shared/resolve-github-context.sh {number})
owner_repo=$(echo "$ctx" | jq -r '"\(.owner)/\(.repo)"')
${CLAUDE_PLUGIN_ROOT}/skills/shared/fetch-pr-context.sh "$owner_repo" {number}
The script returns comments with resolved status. Filter to unresolved only.
For each unresolved comment:
Use comment ID to reply in-thread via GitHub API:
${CLAUDE_PLUGIN_ROOT}/skills/pr-comments/reply-to-comment.sh {owner}/{repo} {number} {comment_id} 'Fixed — [explanation]'
Never: gh pr comment {number} --body='...' (loses thread context)
Never: gh api .../pulls/comments/{id}/replies (endpoint does not exist, returns 404)
Never: raw gh api for replies — always use the script (validates correct PR)
Report:
When a single reviewer has multiple comments:
Group 2-3 small comments into one reply if they're related:
Fixed:
1. Added validation on line 45 (comment #1)
2. Extracted to utility function (comment #2)
Both validated locally before push.
If responses are lengthy or unrelated, reply individually:
Comment #1: Lengthy architectural discussion
Comment #2: Simple typo fix
→ Two separate replies (don't batch)
Multiple comments in the same thread (sub-conversation) → one reply addressing all.
When multiple reviewers comment on same code:
Ensure responses are consistent across reviewers:
Reviewer A: "Extract to function"
Reviewer B: "This function is hard to test"
✅ Unified response: "Extracted to utility and added tests"
❌ Different responses: Looks like we ignored one reviewer
Reply to all comments in the same push cycle. Don't reply to some, ignore others.
If two reviewers disagree, reply:
Good points from both. We've decided on approach X because [reasoning].
Link to GitHub issue for extended discussion if needed.
If reviewer feedback contradicts design or project standards:
I understand the concern about [issue]. However, we're using pattern X
because [project constraint]. If you'd like to discuss alternatives,
let's open a separate issue.
Even if you disagree, acknowledge the valid concern:
❌ Bad: "That's not how we do things here"
✅ Good: "I see the readability concern. We've chosen approach X
because [trade-off]. Happy to discuss in future PRs."
If feedback relates to project standards, link to CLAUDE.md or relevant docs:
Good catch. This follows pattern documented in CLAUDE.md#section.
Let me know if the guidance is unclear.
Fixed — [one sentence what changed].
[If tests added: Also added tests for X.]
Example:
Fixed — Added null check before accessing user.email on line 45.
Also added test case for when user creation fails mid-transaction.
This was addressed in [commit hash] — [brief explanation].
Example:
This was addressed in 3bc4e2a — Validation now happens in middleware
before request reaches the handler.
Acknowledged — [reason for deferring]. Tracked in #NNN.
Example:
Acknowledged — Migrating to async/await is valuable, but out of scope
for this PR. Tracked in #456 for next quarter.
I want to make sure I understand. Can you clarify [specific question]?
Example:
I want to make sure I understand the concern. Are you concerned about
performance at scale, or the maintainability of this pattern in general?
I appreciate the suggestion. However, [reason why we're not doing this].
Let's discuss in [GitHub issue link] if you'd like to revisit.
Example:
I appreciate the suggestion to use immutable data structures. However,
we've benchmarked this code path and mutation is actually faster here.
See discussion in #789 for performance trade-off analysis.
${CLAUDE_PLUGIN_ROOT}/skills/pr-comments/reply-to-comment.sh validates correct PR before postinggh pr comment (loses thread context)gh api for replies — the script prevents wrong-PR and wrong-endpoint mistakes/pulls/comments/{id}/replies — this endpoint does not exist (404)/review-pr — Initial PR review and address feedback/commit — Create commits being replied to