Omh Code Review

---
name: "omh-code-review"
description: "[omh] Hermes Code Review workflow: 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.

## 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`, `+13 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 verdict: what was checked and found clean, and what could not be assessed with the reason. An absent finding is evidence only when the closing says the surface was actually checked.

Handoff policy:

Hermes may frame and summarize review evidence; fixes or code mutations found during review should be delegated to the selected coding executor.

Required inputs:

- diff or files
- expected behavior
- test evidence
- the dispatch Claim and Requirements pointer (issue, plan, or spec section) when intent is reviewable

Expected outputs:

- ranked findings per axis
- spec-axis verdict or a named not-assessed reason
- open questions
- test gaps
- checked-and-clean and could-not-assess lists

Artifact expectations:

- critic run record when review evidence is captured

Safety rules:

- Findings come before summaries.
- Cite concrete evidence for every finding.
- Say clearly when no issue is found.

## Runtime Evidence

Preferred harness for this skill: `critic`.

```sh
omh runtime record --skill code-review --harness critic --status started
```

Record observed delegation results; otherwise return `not_available` or `not_observed`.
Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
- When wrapper metadata includes `memory_review_card/v1` or `handoff_context_pack/v1`, treat it as reviewed OMH-local or wrapper-supplied context only. Use conflict-free context summaries to shape plans and handoffs, but do not claim Hermes internal memory was read or changed.
Preserve workflow intent and stop conditions; verify before claiming completion.

Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.

Shared product, compatibility, topology, memory, harness, and execution rules: `omh-routing/references/skill-common-rail.md`. Load it when applicable; otherwise name an unavailable capability.