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 AI-generated code
Reviews code written by an AI assistant for hallucinated APIs, over-engineering, swallowed errors, weakened tests and copy-paste drift. Use before merging a change an agent produced.
review-ai-generated-codeReview an API change for breaking changes
Reviews an API diff or spec for changes that break existing clients, such as removed fields, changed semantics, new defaults, error changes and versioning gaps. Use before releasing.
review-api-breaking-changesReview a diff for shipping risks
Assesses what can go wrong when a change reaches production, such as broken contracts, unsafe migrations, rollout order and rollback, and proposes mitigations. Use before deploying a risky change.
review-diff-for-risksReview 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-handling