Menu
Respond to PR review comments systematically in thread context
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Open a PR for the current feature branch — validate, self-review, simplify, organize commits, push, create the PR, wait for CI and review, then address feedback. Use when implementation is complete and ready for review.
Write pytest tests using AAA pattern, project naming convention, and helper-based assertions (unwrap_as, unwrap_data, unwrap_unset). Delegates to the test-writer agent.
Review the current branch for correctness, security, architecture, and project conventions before opening a PR. Delegates to the code-reviewer agent and adds StatusPro-specific checks.
Structured code review using 6 dimensions. Works with or without the code-reviewer agent.
Create conventional commits with quality gates and validation
Generate or update docstrings, ADRs, READMEs, cookbook recipes, and user guides. Knows about MCP help-resource drift and ADR numbering scheme.
| 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/skills/pr-comments/reply-to-comment.sh*), Bash(.claude/skills/shared/resolve-github-context.sh*), Bash(.claude/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/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/skills/shared/resolve-github-context.sh {number})
owner_repo=$(echo "$ctx" | jq -r '"\(.owner)/\(.repo)"')
.claude/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/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/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)/code-reviewer — Run a 6-dimension structured review before opening/commit — Create commits being replied to