/omh-code-review

name: "omh-code-review"
description: "[omh] Pull request or changes to vet: bug-first review with evidence. Use when the user says: code-review, review, audit, find bugs, release gate, claim audit, evidence audit, README claim."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, review]
    category: review
    phase: critique
    role: reviewer
    quality_tier: finding-evidence-gated

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.
• Both axes appear in the report: correctness/risk findings, and a spec-axis verdict naming its Claim source or the `not_assessed` reason.
• No-issue reviews still name residual risk, missing tests, and independent review evidence if unavailable.
• The closing carries the checked-and-clean list and the could-not-assess list, each naming its surfaces.
• 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.
• To dispatch a reviewer rather than write the findings yourself, load `omh-code-review/references/review-dispatch.md`; it carries the base-SHA rule and the implementer status contract.
• When findings arrive for work you own, load `omh-code-review/references/review-response.md` before changing anything.
• For maintainability judgement calls, load `omh-code-review/references/smell-baseline.md`; it names the twelve baseline smells with their fixes and the repo-standards-override rule.
• When one bug-first pass is not enough, load `omh-code-review/references/review-lenses.md` and run the five lenses separately; the verification-gap lens asks whether anything would go red if the changed behavior broke.

Workflow Lane

• Current lane: **Coding handoff** (`idea-to-deploy`, `llm-app-dev`, `cto-loop`, `deploy-and-monitor`, `code-review`, `build-failure-triage`, `verification-gate`, `security-safety-review`, `+28 more`) - coding owners, handoffs, review, CI, and merge evidence.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Use When

Use for review-shaped requests; findings come first and must cite concrete evidence.

Strong routing signals: `code-review`, `$code-review`, `review`, `audit`, `find bugs`, `release gate`, `claim audit`, `evidence audit`, `README claim`, `what actually happened`, `code review`, `review gate`, `コードレビュー`, `バグを見つけて`, `実際に何をしたか`, `리뷰`, `코드 리뷰`, `리뷰까지`, `릴리즈 전`, `실제 코드와 맞는가`, `실제로 뭐 했는지`, `검증된 결과`, `代码评审`, `代码审查`, `找出缺陷`

Catalog Metadata

Category: `review` Phase: `critique` Hermes role: `reviewer` Quality tier: `finding-evidence-gated` Reasoning demand: `standard`

Quality bar:

• Lead with ranked findings grounded in file, diff, command, or artifact evidence.
• Separate review findings from fix implementation; fixes become executor work.
• For Hermes-owned coding work, inspect `hermes_coding_harness/v1` and require review evidence before upgrading the reviewer lane.
• Say clearly when no actionable issue is found and name remaining test gaps.
• Report each finding with `priority` (`P0`-`P3`), `confidence`, `evidence`, `path`, and `line_range`, then close with one verdict of `ship` or `no_ship` plus its own `confidence`; a finding without a path and line range is an open question, not a finding.
• `REVIEW.md` in the reviewed repository defines what blocks: map its blocking definitions onto `P0`/`P1` and let a `no_ship` verdict follow from that file rather than from reviewer preference. When the repository has no such file, say which blocking definition was used instead.
• Review on two axes and report them side by side, never re-ranked against each other: the correctness/risk axis judges the code as it is, and the spec axis judges the diff against the dispatch's Claim and Requirements pointer. A clean diff that does not do what was asked is a spec-axis finding; when no Claim or spec pointer was supplied, report the spec axis as `not_assessed` with that reason instead of staying silent.
• Judge maintainability findings against the named baseline in `omh-code-review/references/smell-baseline.md`: a baseline smell is a judgement call to argue from evidence, never an automatic finding, and the reviewed repository's own standards override the baseline wherever they conflict.
• Close with two lists beside the v