Patrones de orquestación de agentes

En OMC, el orquestador (tu sesión principal de Claude Code) nunca escribe código de producción. Toda edición pasa por agentes especializados: executor, designer, writer.

Esta separación significa que el orquestador mantiene una vista de alto nivel, coordina entre agentes y valida resultados — sin perderse en detalles de implementación.

Resultado práctico: puedes supervisar 4-6 workstreams en paralelo porque estás revisando outputs, no produciéndolos.

Toda feature no trivial sigue este flujo:

explore (haiku) → planner (opus) → executor (sonnet) → verifier (sonnet)

1. Explore — Mapea el codebase en 30 segundos. Identifica archivos relevantes, patrones existentes, y dependencias.

2. Planner — Secuencia la implementación en tareas atómicas. Define qué archivos crear/modificar y en qué orden.

3. Executor — Escribe el código siguiendo el plan. Un agente por tarea para mantener contexto limpio.

4. Verifier — Prueba que funciona con evidencia: tests pasan, build compila, la feature hace lo que prometió.

Saltarse el paso de explore es el error más común. Sin él, executor escribe código basado en suposiciones sobre la estructura del proyecto.

/ralph envuelve cualquier tarea en un loop auto-referencial: ejecuta la tarea, verifier comprueba el resultado, y si algo falla, el loop reinicia automáticamente.

/ralph "refactoriza el módulo de auth con cobertura completa de tests"

Claude Code no para hasta que el linting está limpio, los tests pasan y el verifier confirma evidencia de corrección.

El mensaje del sistema "The boulder never stops" es la señal de que ralph está activo — el agente sigue adelante incluso si pasos individuales fallan.

Úsalo para tareas donde no puedes permitirte un resultado parcial.

/team usa el sistema de equipos nativos de Claude Code para correr un pipeline coordinado:

team-plan → team-prd → team-exec → team-verify → team-fix (loop)

Cada etapa enruta al agente correcto:

Etapa	Agentes
team-plan	explore (haiku) + planner (opus)
team-prd	analyst (opus) + critic
team-exec	executor (sonnet) + specialists
team-verify	verifier + security-reviewer
team-fix	executor / build-fixer / debugger

El estado se persiste en .omc/state/team-state.json, así que puedes retomar después de un crash o reset de contexto.

/team "construir sistema de notificaciones con email y push"

Cada agente tiene un propósito específico y un modelo asignado:

Análisis y planificación:

• explore (haiku) — descubrimiento de codebase, mapeo de símbolos
• analyst (opus) — requisitos, criterios de aceptación
• planner (opus) — secuenciación de tareas, planes de ejecución
• architect (opus) — diseño de sistema, boundaries, interfaces

Implementación:

• executor (sonnet) — código, refactoring, features
• designer (sonnet) — UX/UI, diseño de interacción
• writer (haiku) — documentación, guías

Calidad:

• verifier (sonnet) — evidencia de completitud
• quality-reviewer (sonnet) — defectos de lógica, anti-patrones
• security-reviewer (sonnet) — vulnerabilidades, trust boundaries
• code-reviewer (opus) — revisión comprehensiva

Debugging:

• debugger (sonnet) — análisis de causa raíz
• build-fixer (sonnet) — errores de TypeScript y build

Situación	Patrón
Feature simple (1-3 archivos)	executor directo
Feature media (4-10 archivos)	explore → planner → executor → verifier
Feature grande (+10 archivos)	/team
Bug conocido	debugger → executor → verifier
Bug misterioso	/ralph con debugger
Refactor grande	/team con architect
Código crítico (auth, payments)	Pipeline + security-reviewer + code-reviewer

La regla general: más agentes = más coste pero más fiabilidad. Para un endpoint de health check, executor directo. Para un sistema de pagos, /team con todas las revisiones.

Con estos patrones, tienes la base para usar OMC en tareas complejas:

• Instalar oh-my-claudecode — si aún no lo tienes instalado
• De idea a deploy — el flujo completo de trabajo
• CLAUDE.md: la guía definitiva — el contexto que alimenta a todos estos agentes