hermes

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.

context

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.

task

Work through these review comments:

Mode: .

  1. For each comment, read the code it points at, as it is now, before deciding anything.
  2. 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.
  1. When two comments conflict, say so and propose one resolution.
  2. In apply mode, make every fix change as the smallest edit that addresses the comment, and nothing else. In plan mode, change no files.
  3. Draft a short reply for each comment.
constraints
  • 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.
output format

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

Edit on GitHubReport a problem

use in

Hodios CLI
npx @hermes-hq/hodios install respond-to-review-comments --target claude-code
Agent Skills
npx skills add hermes-hq/hodios-dist --skill respond-to-review-comments -a claude-code
Add the Hodios marketplace (once)
claude plugin marketplace add hermes-hq/hodios-dist
Install the software-engineering plugin
claude plugin install hodios-software-engineering@hodios

The plugin brings every entry in this domain at once.

pairs well with

All of Code review
PersonaCode review

Code 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-reviewer
PromptCode review

Review 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-request
PromptCode review

Review 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-code
PromptCode review

Review 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-changes
PromptCode review

Review 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-risks
PromptCode review

Review 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