Communitygithub.com

omc-review

Evalúa el trabajo finalizado en busca de defectos, riesgos y simplificaciones antes de que se implemente.

¿Qué es omc-review?

El skill 'omc-review' permite evaluar código o trabajo ya existente sin modificarlo. Es el flujo de revisión canónico, diseñado para detectar defectos, riesgos y oportunidades de simplificación antes de que una entrega llegue a producción. Soporta plataformas como Claude Code y Cursor, y se integra con flujos como 'merge-readiness' (que redirige aquí) y 'ai-slop-cleaner' (un carril optativo). El proceso se basa en: entender el cambio y su intención, verificar corrección primero, luego riesgo y simplificación, y validar cada hallazgo antes de reportarlo. Las salidas incluyen hallazgos ordenados por gravedad, con archivo, línea y escenario concreto, así como lo revisado sin problemas y lo que no pudo evaluarse. Es un skill de asesoría (no bloqueante), excepto para puertas duras como seguridad o operaciones destructivas.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Yeachan-Heo/oh-my-claudecode/tree/main/skills/review

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Revisión

Usa este skill para evaluar trabajo que ya existe. La revisión nunca escribe el cambio que está juzgando.

Este es el flujo de revisión canónico. merge-readiness redirige aquí, y ai-slop-cleaner es un carril optativo dentro de él.

Objetivo

Encontrar lo que realmente está mal, clasificado por gravedad, con suficiente detalle para actuar.

Flujo de trabajo

  1. Establecer qué cambió y qué se pretendía lograr.
  2. Leer el cambio en función de esa intención.
  3. Verificar primero la corrección, luego el riesgo, luego la simplificación.
  4. Confirmar cada posible hallazgo antes de reportarlo.
  5. Reportar los hallazgos del más grave al menos grave.

Qué verificar

  • Corrección — defectos lógicos, casos límite, rutas de error, concurrencia
  • Riesgo — límites de seguridad, operaciones destructivas, integridad de datos
  • Reutilización — utilidades o patrones existentes que el cambio debería haber usado
  • Simplificación — código que podría eliminarse o colapsarse
  • Cobertura — comportamiento que se entrega sin pruebas

Reglas

  • Carriles separados: el revisor no debe tener el mismo contexto activo que el autor.
  • Verificar antes de reportar. Un hallazgo que suena plausible pero no se reproduce es ruido.
  • Indicar la gravedad con honestidad; no inflar la lista para parecer exhaustivo.
  • "Sin hallazgos" es un resultado válido cuando el trabajo es sólido.
  • Asesoría por defecto — la revisión informa, no bloquea. Las puertas duras (publicación, seguridad, operaciones destructivas) permanecen separadas y fallan de forma cerrada.

Salida

  • Hallazgos, del más grave al menos grave, cada uno con archivo, línea y escenario concreto de fallo
  • Lo que se verificó y encontró limpio
  • Cualquier cosa que no pudo evaluarse

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

agent-doc-discipline

Writing-time discipline for documents agents consume (the five surfaces, specs, tickets, .omc/skills/) — every rule checkable and carrying a why, steps before reference, one meaning in one home, no restating what the environment already says. Mandatory at drydock seed generation and the launch C5 sediment pass; opt-in for any other agent-facing doc edit. The companion of minimal-code-discipline: that one disciplines code, this one disciplines papers.

ai-slop-cleaner

Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode

ask

Process-first advisor routing for Claude, Codex, Gemini, Antigravity, Grok, or Cursor via `omc ask`, with artifact capture and no raw CLI assembly

ask-navigator

Shipyard

autopilot

Full autonomous execution from idea to working code

autoresearch

Stateful single-mission improvement loop with strict evaluator contract, markdown decision logs, and max-runtime stop behavior

cancel

Cancel any active OMC mode (autopilot, ralph, ultragoal, swarm, ultrapilot, pipeline, team) and clean up retired legacy state

configure-notifications

Configure notification integrations (Telegram, Discord, Slack) via natural language

debug

Diagnose the current OMC session or repo state using logs, traces, state, and focused reproduction

deepinit

Deep codebase initialization with hierarchical AGENTS.md documentation

deep-interview

Socratic deep interview with mathematical ambiguity gating before explicit execution approval

drydock

Lay the keel of the shipyard harness in any repo — the 4-pillar shared environment (Context, Rules, Tools, Standards) across 5 surfaces (CLAUDE.md, skills, design-system, mcp/cli, shared context) so that every human and agent inherits the same design language and anyone can ship. Run once per repo; re-run with --check to audit drift.

execute

Carry an approved task through to working, verified code

external-context

Invoke parallel document-specialist agents for external web searches and documentation lookup

graph

Deterministic orchestration graph runtime - declarative DAG pipelines with journal-based crash recovery

harbor

Harbor intake for external work — the captain only handles unresolved decisions. Sweeps incoming issues and PRs, verifies every claim before disposition, reuses every decision already made, and hands the maintainer a docket whose pending items each carry one question with options, recommendation, impact and evidence. Agent-autonomous for facts and for actions covered by standing authorization; signed for every new judgment. Never merges.

hud

Configure HUD display options (layout, presets, display elements)

launch

Shipyard

loft

Loft the shape before cutting steel — answer a design question that prose cannot settle by building a throwaway artifact: a pure logic module in a clickable shell, or structurally different UI variants behind one route. The captain reacts to the artifact; the answer folds into the decision; the artifact never docks. Use when a design question stalls in words, when a navigator map carries a loft ticket, or when a spec discussion reaches

minimal-code-discipline

YAGNI-ladder coding discipline for writing changes — existence-first, reuse before writing, dependency ladder, shortest correct diff, with non-negotiables that must never be minimized away

Skills relacionados