1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
---
description: Process pending review comments on a PR through five steps (Gather, Evaluate, Respond, Implement, Report). Each comment is verified against the actual codebase before action — restated in your own words, checked for accurate premise, YAGNI-tested if it suggests "more proper" architecture without current consumers, then categorized as correct-and-actionable, correct-but-out-of-scope, debatable, or incorrect. Disagreement is framed with code references rather than opinion. Implementation handles simple fixes first, tests each change individually, commits with conventional messages that name the fix. Final report lists what was implemented, what was deferred to follow-up issues, and what still needs discussion. Use when responding to PR review feedback. Do NOT use for proactively reviewing code (use `/review-code`), for the publish flow itself (use the Review-and-Publish steps in `commits.md`), or when the PR has no review comments yet.
disable-model-invocation: true
---
# /respond-to-review — Evaluate and Implement Code Review Feedback
Evaluate code review feedback technically before implementing. Verify suggestions against the actual codebase — don't implement blindly.
## Usage
```
/respond-to-review [PR_NUMBER]
```
If no PR number is given, check the current branch's open PR for pending review comments.
## Instructions
### 1. Gather the Feedback
- Fetch *unresolved review threads*, not a flat comment list. Resolution state lives only in the GraphQL API: query `repository.pullRequest.reviewThreads` (with `isResolved` and each thread's comments) via `gh api graphql`, and skip threads already resolved so settled feedback isn't re-processed.
- Also fetch top-level PR conversation comments via `gh api repos/{owner}/{repo}/issues/{number}/comments` — those aren't threaded and have no resolution state.
- Read each thread in full and group related ones by the change they request — reviewers often split one concern across several comments.
### 2. Evaluate Each Item
For each review comment, before implementing anything:
1. **Restate the suggestion in your own words** — make sure you understand what's being asked. If you can't restate it clearly, ask for clarification before touching code.
2. **Verify against the codebase** — check whether the reviewer's premise is correct. Reviewers sometimes misread code, miss context, or reference outdated patterns. Read the actual code they're commenting on.
3. **Check YAGNI** — if the reviewer suggests a "more proper" or "more robust" implementation, grep the codebase for actual usage. If nothing uses the suggested pattern today, flag it: "This would add complexity without current consumers. Should we defer until there's a concrete need?"
4. **Assess the suggestion** — categorize as:
- **Correct and actionable** — implement it
- **Correct but out of scope** — acknowledge and create a follow-up issue
- **Debatable** — present your reasoning and ask for the reviewer's perspective
- **Incorrect** — explain why with evidence (file paths, test results, documentation)
### 3. Respond
- Lead with technical substance, not agreement
- If you disagree, explain why with code references — not opinion
- If you're unsure, say so and ask a specific question
- Never implement a suggestion you don't understand
### 4. Implement
- Address simple fixes first, complex ones after
- Test each change individually — don't batch unrelated fixes into one commit
- Run the full test suite after all changes
- After a fix is verified, reply on its review thread and resolve it — resolve only after verification, never before, so an unverified change can't quietly close out feedback
- Commit with conventional messages that name the actual fix (`fix: validate export filename`), not the review that prompted it. What changed and why goes in the commit; how it surfaced belongs in the PR thread, not `git log`.
### 5. Report
- Summarize what was implemented, what was deferred, and what needs discussion
- Link any follow-up issues created for out-of-scope suggestions
## Content scope
Output this skill produces that gets committed or shared with the team must follow the *Content scope for public artifacts* rule in [`commits.md`](../claude-rules/commits.md): no local paths, no private repo names, no personal tooling references.
|
