Review

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

1. Establish what changed and what it was meant to do.
2. Read the change against that intent.
3. Check correctness first, then risk, then simplification.
4. Verify each candidate finding before reporting it.
5. 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.md or 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

Quality Gates

Before finalizing the review, check the existing merged OMC qualityGates["omc-review"] entries (project stage entries replace the user list; see docs/quality-gates-configuration.md). If there are no entries, do not call omc quality-gates list, spawn gate tasks, or add a Quality Gates section or gate records to the review output. If there is at least one entry, call omc quality-gates list --stage omc-review --json and show every validation error. For each available gate, spawn one independent Claude Code Task that loads the named skill from resolvedPath, reviews the same changes, and returns VERDICT: PASS or VERDICT: BLOCK plus findings. Use the configured model override when present; do not pass another reviewer's output to the gate. Reuse the same gate lane if the change is revised and reviewed again.

When gates are configured, record { gate, mode, verdict } for each gate in a Quality Gates section of the review output. Unresolved skills are gate_unavailable with a visible warning, never PASS; they do not fail the review stage. A blocking BLOCK makes the overall result REQUEST CHANGES; advisory results are informational and never block.