[omh] Hermes Code Review workflow: bug-first review with evidence.
SkillScore73Maintained
Automatic
◆Coding pack
Last verified 8/18/2026
What it changes
Passed 15 of 20 test cases with the skill, and 9 of 20 without it.
Without skill45%
With skill73%
Checks it passed that the model alone missed
States that no actionable findings were identified in the diff
Maps repository blocking definitions onto P0 or P1 priority findings
Delegates the implementation or code fix step to a separate coding executor
and 4 more in the full report
7 fixed9 passed either way5 still failing1 broke
Pass-rate lift
+27 pp
Tokens
+104%
Agent turns
0%
Response time
-2%
Model gemini-3.6-flashMeasured 8/18/2026v316 of 22 cases passed with skill · 20 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
For Hermes-owned coding changes, what requirement must be fulfilled before upgrading the reviewer lane?
What was checked, without and with the skill
Checked
Without skill
With skill
Requires explicit review evidence from inspecting the coding harness before lane upgrade
Missed
Passed
case-22 · gemini-3.6-flash · 8/18/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md114 lines3 files
Code Review
This is a Hermes-native code-review workflow skill.
Why This Exists
code-review exists to make review bug-first and evidence-grounded: findings must cite concrete files, diffs, commands, or artifacts before any summary or fix proposal.
Do Not Use When
The user asks to implement the fix rather than review existing code or claims.
There is no diff, file set, claim, artifact, or expected behavior to review.
The request is broad product critique, strategy, or planning rather than code or evidence review.
Examples
Good example:
Prompt: $code-review review this PR for install/update UX regressions and missing tests.
Expected behavior: Lead with ranked findings, cite concrete evidence, then list open questions and test gaps.
Why: The task is explicitly review-shaped and has a behavioral risk surface.
Bad example:
Prompt: $code-review add the missing setup flag and commit it.
Expected behavior: Route implementation to a selected executor/runtime after review findings are established.
Why: Review can identify the issue, but code mutation is a separate execution step.
Completion Checklist
Findings come first and are ranked by severity before summary or praise.
Every finding cites file, diff, command output, artifact, or expected behavior evidence.
No-issue reviews still name residual risk, missing tests, and independent review evidence if unavailable.
Fix implementation, architecture follow-up, and CI/merge claims stay separate from the review result.
Recovery Notes
If no diff, file set, PR, or artifact is available, inspect the requested target or ask one target question before reviewing.
If tests fail or are missing, cite the exact command gap and do not approve the change as verified.
If independent review evidence is unavailable, say so directly instead of implying a second reviewer passed it.