Respond to code review comments
Triages each review comment as fix, discuss or decline with a reason, drafts the replies, and applies the agreed fixes. Use when a pull request comes back with reviewer feedback.
Review feedback is a mix of real defects, preferences, questions and misunderstandings. Accepting everything bloats the change and sometimes makes it worse; arguing with everything burns trust. Each comment deserves a decision with a reason the reviewer can accept.
Work through these review comments:
Mode: .
- For each comment, read the code it points at, as it is now, before deciding anything.
- Classify it:
- fix: the reviewer is right, or the change is cheap and harmless.
- discuss: it is a trade-off, a question, or you need information the reviewer has.
- decline: it is wrong, out of scope for this change, or conflicts with another requirement. Give the concrete reason, and offer a follow-up issue when it is out of scope.
- When two comments conflict, say so and propose one resolution.
- In
applymode, make every fix change as the smallest edit that addresses the comment, and nothing else. Inplanmode, change no files. - Draft a short reply for each comment.
- Be honest about reviewer mistakes, but polite. Show the evidence (code, docs, a test) instead of asserting.
- Never make an unrequested change while applying a fix.
- If a comment is ambiguous, classify it discuss and ask one precise question rather than guessing what the reviewer meant.
- Replies are plain and specific: what you changed and where, or why not. No thanking boilerplate, no apologies.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
Triage
A table: # | Comment (short) | Decision (fix, discuss, decline) | Reason.
Changes
In apply mode: the diff, grouped by comment number, plus the result of any test you ran. In plan mode: "None (plan mode)".
Replies
For each comment number, the reply text, ready to paste.
1 required value still a placeholder; the assistant will ask for it.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Software engineering
- category
- Code review
- level
- Intermediate
- made for
- Software engineer
- needs
- repo-read, file-write
- risk
- edits-files
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md
use in
npx @hermes-hq/hodios install respond-to-review-comments --target claude-codenpx skills add hermes-hq/hodios-dist --skill respond-to-review-comments -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-software-engineering@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of Code reviewCode reviewer
Reviews changes like a senior engineer who blocks only on real defects, backs every finding with a triggering input, and keeps style opinions out. Use as a reviewer persona or subagent.
code-reviewerReview a pull request
Reviews a pull request diff for correctness bugs, risky changes and missing tests, and returns ranked findings. Use before merging a PR, branch or diff.
review-pull-requestReview error handling
Reviews failure paths for swallowed errors, lost context, unsafe retries, missing timeouts and internal details leaking to users, with ranked fixes. Use on code that calls I/O or external services.
review-error-handlingWrite code review guidelines
Writes a team's code review guidelines covering what blocks a merge, comment labels, size limits, response times, author and reviewer duties and how to disagree. Use when setting review norms.
write-code-review-guidelinesSelf-review a branch before opening a PR
Reviews your own branch the way a strict reviewer would, catches debug leftovers, unrelated changes, missing tests and leaked secrets, and runs the checks. Use before requesting review.
self-review-before-prWalk a reviewer through a pull request
Explains a large or unfamiliar pull request to its reviewer with what changes and why, a reading order, the risky hunks and questions for the author. Use before reviewing a big diff.
walk-through-pull-request