菜单
Respond to PR review comments systematically in thread context
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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