About omc-review
omc-review is a workflow skill for assessing existing changes without authoring them. It verifies candidate findings, ranks issues by severity, and states what was checked or could not be assessed.
Key features
- 01Establish the change and its intent
- 02Prioritize correctness and risk checks
- 03Verify candidate findings before reporting
- 04Rank findings by severity
- 05Review substantial changes on separate standards and intent axes
Use cases
- 01Review completed code changes
- 02Check security boundaries and data integrity risks
- 03Assess whether changes meet requirements and have test coverage
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/omc-reviewin Claude Code to confirm it loaded.
Details
From the project READMEReview
Use this skill to evaluate work that already exists. Review never authors the change it is judging.
This is the canonical review workflow. ai-slop-cleaner is an opt-in lane
within it.
Goal
Find what is actually wrong, ranked by severity, with enough detail to act on.
Workflow
- Establish what changed and what it was meant to do.
- Read the change against that intent.
- Check correctness first, then risk, then simplification.
- Verify each candidate finding before reporting it.
- Report findings most-severe first.
What to check
- Correctness — logic defects, edge cases, error paths, concurrency
- Risk — security boundaries, destructive operations, data integrity
- Reuse — existing utilities or patterns the change should have used
- Simplification — code that could be deleted or collapsed
- Coverage — behavior that ships untested
Two axes, run apart
A substantial diff is reviewed as two parallel sub-agent passes, reported separately — never merged or cross-ranked, because a change can pass one axis and fail the other (standards-conforming but wrong behavior; faithful but convention-breaking):
- Standards axis — the diff against the repo's documented standards plus a judgement-call-only smell baseline; anything tooling already enforces is skipped. The standards set is discovered, not assumed: search the repo for standards documents (CLAUDE.md/AGENTS.md,
docs/standards/volumes,CONTRIBUTING.md,CODING_STANDARDS.mdor equivalents) and review against whatever exists — a standards file you didn't look for is a standard you didn't apply. - Intent axis — the diff against what the work was meant to do — the task, spec, or ticket acceptance criteria: requirements missing or partial, behavior nobody asked for, each finding quoting its source line.
Keep each sub-agent brief under ~400 words and pointed at one axis. Aggregate without picking a single winner across axes — that reranking is what the separation exists to prevent; state each axis's verdict on its own. A small diff stays one pass.
Rules
- Separate lanes: the reviewer must not be the author's same active context.
- Verify before reporting. A plausible-sounding finding that does not reproduce is noise.
- State severity honestly; do not pad the list to look thorough.
- "No findings" is a valid result when the work is sound.
- Advisory by default — review informs, it does not gate. Hard gates (release, security, destructive operations) stay separate and fail closed.
Output
- Findings, most-severe first, each with file, line, and concrete failure scenario
- What was checked and found clean
- Anything that could not be assessed