Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add 42-evey/hermes-plugins --skill review-feedbackgit clone --depth 1 https://github.com/42-evey/hermes-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/42-evey/hermes-plugins/review-feedback)<a href="https://agentmods.dev/skills/42-evey/hermes-plugins/review-feedback"><img src="https://agentmods.dev/badge/skills/42-evey/hermes-plugins/review-feedback/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/42-evey/hermes-plugins/review-feedback"><img src="https://agentmods.dev/badge/skills/42-evey/hermes-plugins/review-feedback.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00016 | $0.00952 |
| Opus 5.5 | $0.00006 | $0.00381 |
| Sonnet 5.5 | $0.00003 | $0.00190 |
| Haiku 4.5 | $0.00002 | $0.00095 |
Grade A, and why
review-feedback scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Review Feedback
Check each review comment against the code before changing anything, then implement accepted items one at a time. Agreeing and disagreeing both need evidence. Asking for a review is requesting-code-review.
When to Use
- A reviewer, maintainer, CI bot or subagent reviewer leaves comments on your change
- The user pastes review notes or says "address the feedback"
- A PR has unresolved review threads
- Don't use for: requesting a review, or writing one
Procedure
- Collect every item. Pull all comments into a numbered list with file:line:
terminal("gh pr view <n> --comments")for the conversation,terminal("gh api repos/{owner}/{repo}/pulls/<n>/comments")for inline threads. Track them withtodo. Done when every comment is one numbered item. - Clarify before implementing any. If any item is ambiguous, ask about those items first and change nothing yet. Items are often related; a misread one changes how the others should be done.
- Check each item against the code. Read the referenced code and answer:
- Is the claim true in this codebase, at this commit?
- Would the change break callers or existing behavior? (
search_filesfor usages) - Does the reviewer lack context you have (platform constraint, earlier decision, compatibility need), or have context you lack?
- Is the code being polished used at all? If nothing calls it, propose removing it instead. Record a verdict per item: accept, push back, or needs clarification.
- Push back with evidence. When an item is wrong, reply with the specific reason: the caller, the test, the spec line, the output that shows it. Offer an alternative if there is one. If the item conflicts with a decision the user made, take it to the user.
- Order accepted items. Blocking issues (bugs, security, data loss) first, then simple fixes, then refactors.
- Implement one at a time. Make one change, run the tests covering it, move to the next. Done per item when its tests are green and the diff holds only that item.
- Reply per thread. Answer inline comments in their thread (
gh api repos/{owner}/{repo}/pulls/<n>/comments/<id>/replies -f body="..."), not as a new top-level comment. State what changed and where ("Fixed in a1b2c3d: null check before parse; test in tests/test_parse.py") or why it was not changed. - Verify the whole change with
verify-before-donebefore reporting the feedback addressed.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today First seen · 64 lines · 16 tokens per session scan A 3cea9b41abba
review-feedback is a skill published in the GitHub repository 42-evey/hermes-plugins (534 stars, last pushed today), licensed MIT. It adds 16 tokens to every session and 952 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-25.
Other skills, from other repositories
repo-readiness-audit
Use when a user asks whether an identified repository is ready for further development, release work, a new feature, handoff, or a new contributor, requiring a disciplined read-only audit before an evidence-backed verdict.
hermes-change-review
Use when a branch, pull request, Kanban task, or implementation must be reviewed separately for intent fidelity, repository quality, and verification evidence before completion or merge is accepted.
orchestrate
Coordinate an active Hardproof run across discovery, design, planning, implementation, review, verification, delivery, and learning.
review
Challenge a Hardproof implementation during REVIEW against its approved contract, code quality, tests, and risk boundaries.
subagent-driven-development
Execute implementation plans by dispatching fresh subagents per task with systematic two-stage review.
github-workflows
Use this skill for the full GitHub operating loop: 1) authenticate, 2) manage repos and remotes, 3) open and review PRs, 4) work on issues, and 5) monitor CI.