con un clic
respond-to-pr-review
// Use when PR review comments need to be processed and responded to, when the user says "respond to review", "handle PR comments", "address review feedback", or after receiving code review on a pull request
// Use when PR review comments need to be processed and responded to, when the user says "respond to review", "handle PR comments", "address review feedback", or after receiving code review on a pull request
Guide for adding new MCP tools with consistent patterns for schemas, tool definitions, registry updates, and Better Auth integration
Spawn parallel subagents to criticize implementation plans from multiple perspectives (duplication, correctness, security, performance, testing, architecture, scope), then improve the plan based on feedback. Use when reviewing a plan before implementation or when stress-testing a plan for gaps.
Analyze the git diff between the current branch and main from multiple perspectives (duplication, correctness, security, performance, testing, architecture, scope) using parallel subagents, then produce a remediation plan for issues found. Use when reviewing branch changes before merge, after implementation, or when the user asks to critique or review current code changes.
Prepare code for review by running quality checks, creating conventional commits, and opening pull requests. Use when the user wants to commit changes, create a PR, prepare for code review, or asks to commit their work.
| name | respond-to-pr-review |
| description | Use when PR review comments need to be processed and responded to, when the user says "respond to review", "handle PR comments", "address review feedback", or after receiving code review on a pull request |
Process all unaddressed PR review comments in parallel. Each comment gets a dedicated subagent that either applies the fix or replies with technical reasoning for disagreement.
Core principle: Every comment deserves a thoughtful technical evaluation - not performative agreement or blind implementation.
digraph {
rankdir=TB;
detect [label="Detect PR from branch" shape=box];
fetch [label="Fetch top-level comments\n(skip replies)" shape=box];
filter [label="Filter to unaddressed\n(no reply from us)" shape=box];
spawn [label="Spawn parallel subagents\n(one per comment)" shape=box];
done [label="Report summary" shape=box];
detect -> fetch -> filter -> spawn -> done;
}
PR_NUMBER=$(gh pr view --json number --jq '.number')
REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
gh api "repos/${REPO}/pulls/${PR_NUMBER}/comments" \
--paginate \
--jq '[.[] | select(.in_reply_to_id == null) | {id, path, line: (.line // .original_line), body, diff_hunk}]'
A comment is "addressed" if it already has a reply. Check by fetching all comments and looking at in_reply_to_id references:
# Get IDs that have been replied to
REPLIED_IDS=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/comments" \
--paginate \
--jq '[.[] | select(.in_reply_to_id != null) | .in_reply_to_id] | unique')
Skip any comment whose id appears in REPLIED_IDS.
Use the Agent tool with subagent_type: "general-purpose" for each unaddressed comment. Launch all subagents in parallel (single message with multiple Agent tool calls).
For each comment, provide this prompt to the subagent:
You are processing a PR review comment. Your job:
1. READ the comment below and understand what change is being requested
2. READ the actual file at the referenced path to understand current code
3. EVALUATE: Does this suggestion make technical sense for this codebase?
4. ACT: Either fix the code OR reply explaining why you disagree
## The Review Comment
- **File**: {path}
- **Line**: {line}
- **Comment**: {body}
- **Diff context**:
```
{diff_hunk}
```
## Rules
- If the fix makes sense: Apply it using the Edit tool, then reply confirming:
```bash
gh api "repos/{REPO}/pulls/{PR_NUMBER}/comments/{COMMENT_ID}/replies" -f body="Fixed."
```
- If you disagree: Reply with concise technical reasoning:
```bash
gh api "repos/{REPO}/pulls/{PR_NUMBER}/comments/{COMMENT_ID}/replies" -f body="[your reasoning]"
```
- Do NOT use performative language ("Great point!", "You're right!")
- Do NOT implement blindly - verify the suggestion is correct first
- Keep replies short and technical
- If the comment contains a "Prompt for AI" section in a <details> block, you can use it as guidance but still verify independently
After all subagents complete, report:
| Mistake | Fix |
|---|---|
| Processing reply comments as top-level | Filter in_reply_to_id == null |
| Responding to already-addressed comments | Check for existing replies first |
| Performative agreement in replies | State the fix or technical reasoning only |
| Fixing without reading the full file | Always read file before editing |
| Ignoring diff_hunk context | Use it to understand what code changed |