equipo

Habilidad Team

Genera N agentes coordinados que trabajan en una lista de tareas compartida utilizando el equipo de agente implícito de Claude Code. Claude Code 2.1.178+ eliminó los TeamCreate/TeamDelete nativos; con CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, cada sesión tiene un equipo implícito y los compañeros se generan directamente con la herramienta Agent/Task usando valores de name distintos. Esta habilidad aún conserva la orquestación heredada de trabajadores tmux/CLI de OMC donde está documentada (omc team / /omc-teams).

El alias de compatibilidad swarm fue eliminado en #1131.

Uso

/oh-my-claudecode:team N:tipo-agente "descripción de la tarea"
/oh-my-claudecode:team "descripción de la tarea"
/oh-my-claudecode:team ralph "descripción de la tarea"

Parámetros

• N - Número de agentes compañeros (1-20). Opcional; por defecto se ajusta automáticamente según la descomposición de la tarea.
• tipo-agente - Agente OMC a generar para la etapa team-exec (p. ej., executor, debugger, designer, codex, gemini, antigravity). Opcional; por defecto sigue el enrutamiento basado en la etapa. Usa codex para generar trabajadores de Codex CLI, gemini para trabajadores de Gemini CLI (nivel empresarial/clave API), o antigravity para trabajadores de Antigravity CLI (agy) (el sucesor de Google para Gemini CLI; requiere las respectivas CLI instaladas). Consulta Enrutamiento de Agentes por Etapa más abajo.
• tarea - Tarea de alto nivel a descomponer y distribuir entre los compañeros.
• ralph - Modificador opcional. Cuando está presente, envuelve el pipeline del equipo en el bucle de persistencia de Ralph (reintento en caso de fallo, verificación del arquitecto antes de la finalización). Consulta Composición Team + Ralph más abajo.

Ejemplos

/team 5:executor "corregir todos los errores de TypeScript en todo el proyecto"
/team 3:debugger "corregir errores de compilación en src/"
/team 4:designer "implementar diseños responsivos para todos los componentes de página"
/team "refactorizar el módulo de autenticación con revisión de seguridad"
/team ralph "construir una API REST completa para la gestión de usuarios"
# Con trabajadores de Codex CLI (requiere: npm install -g @openai/codex)
/team 2:codex "revisar la arquitectura y sugerir mejoras"
# Con trabajadores de Gemini CLI (requiere: npm install -g @google/gemini-cli)
/team 2:gemini "rediseñar los componentes de la interfaz de usuario"
# Con trabajadores de Antigravity CLI (requiere: instalar según https://antigravity.google)
/team 2:antigravity "rediseñar los componentes de la interfaz de usuario"
# Mixto: Codex para análisis de backend, Gemini/Antigravity para frontend (delegar por tarea con /oh-my-claudecode:ask)

Arquitectura

Usuario: "/team 3:executor corrige todos los errores de TypeScript"
              |
              v
      [ORQUESTADOR DEL EQUIPO (Líder)]
              |
              +-- Usa el equipo implícito de Claude Code de la sesión
              |       -> sin llamada a TeamCreate; el líder sigue siendo la sesión actual
              |
              +-- Analiza y descompone la tarea en subtareas
              |       -> explore/architect produce una lista de subtareas
              |
              +-- Crea entradas en la lista de tareas a partir del plan de implementación
              |       -> entradas TODO/tarea #1, #2, #3 con dependencias
              |
              +-- Actualiza las entradas de la lista de tareas (asigna propietarios previamente)
              |       -> tarea #1 propietario=trabajador-1, etc.
              |
              +-- Tarea(name="trabajador-1") x 3
              |       -> genera compañeros en el equipo
              |
              +-- Bucle de monitoreo
              |       <- mensajes de compañeros (entregados automáticamente por la superficie activa del equipo)
              |       -> revisión de la lista de tareas/TodoWrite para progreso
              |       -> enviar mensajes a los compañeros a través de la superficie activa del equipo para desbloquear/coordinar
              |
              +-- Finalización
                      -> solicitar apagado a cada compañero a través de la superficie activa del equipo
                      <- acuse de recibo de apagado de los compañeros
                      -> limpiar el estado del equipo OMC (sin llamada a TeamDelete)
                      -> rm .omc/state/team-state.json

Modelo de equipo nativo de Claude Code (2.1.178+):

- Esta habilidad no crea ningún directorio ~/.claude/teams/<nombre>/ por equipo.
- No hay llamadas TeamCreate/TeamDelete disponibles.
- `team_name` es aceptado por Claude Code nativo solo como metadato heredado ignorado; no confíes en él para el enrutamiento.
- Genera compañeros directamente a través de Agent/Task con `name="trabajador-N"`.

Relación con el Flujo de Trabajo de Objetivos

Team es la autoridad de OMC para la ejecución paralela y por etapas. Usa las políticas de conflicto deterministas refuse, adopt_existing y artifact_only en lugar del manejo de advertencias no determinista. Si una tarea menciona /goal de Claude Code, Ralph o Ultragoal solo de artefactos, mantén a Team como la autoridad principal del bucle a menos que el líder entregue explícitamente el control. Usa /goal solo como un objetivo de entrega documentado de Claude Code nativo o como evidencia visible de la sesión líder; no afirmes que el evaluador de /goal ejecuta comandos de forma independiente, lee archivos o reemplaza team-verify/team-fix. Las referencias a Ultragoal solo de artefactos deben tratarse como un libro de contabilidad duradero de objetivos/puntos de control/evidencia de artefactos, no como ejecución de trabajadores por sí mismos.

Pipeline por Etapas (Entorno de Ejecución de Equipo Canónico)

La ejecución del equipo sigue un pipeline por etapas:

team-plan -> team-prd -> team-exec -> team-verify -> team-fix (bucle)

Enrutamiento de Agentes por Etapa

Cada etapa del pipeline utiliza agentes especializados — no solo ejecutores. El líder selecciona agentes según la etapa y las características de la tarea.

Etapa	Agentes Requeridos	Agentes Opcionales	Criterios de Selección
team-plan	explore (haiku), planner (opus)	analyst (opus), architect (opus)	Usa analyst para requisitos poco claros. Usa architect para sistemas con límites complejos.
team-prd	analyst (opus)	critic (opus)	Usa critic para desafiar el alcance.
team-exec	executor (sonnet)	executor (opus), debugger (sonnet), designer (sonnet), writer (haiku), test-engineer (sonnet)	Empareja el agente con el tipo de subtarea. Usa executor (modelo=opus) para trabajo autónomo complejo, designer para interfaz de usuario, debugger para problemas de compilación, writer para documentación, test-engineer para creación de pruebas.
team-verify	verifier (sonnet)	test-engineer (sonnet), security-reviewer (sonnet), code-reviewer (opus)	Siempre ejecuta verifier. Agrega security-reviewer para cambios en autenticación/criptografía. Agrega code-reviewer para más de 20 archivos o cambios arquitectónicos. code-reviewer también cubre verificaciones de estilo/formato.
team-fix	executor (sonnet)	debugger (sonnet), executor (opus)	Usa debugger para errores de tipo/compilación y aislamiento de regresiones. Usa executor (modelo=opus) para correcciones complejas de múltiples archivos.

Reglas de enrutamiento:

1. El líder elige los agentes por etapa, no el usuario. El parámetro N:tipo-agente del usuario solo anula el tipo de trabajador de la etapa team-exec. Todas las demás etapas utilizan especialistas apropiados para la etapa.
2. Los agentes especialistas complementan a los agentes ejecutores. Enruta el análisis/revisión a agentes arquitecto/crítico de Claude y el trabajo de interfaz de usuario a agentes diseñadores. Los trabajadores de CLI tmux son de un solo uso y no participan en la comunicación del equipo.
3. El modo de costo afecta el nivel del modelo. En degradación: agentes opus a sonnet, sonnet a haiku donde la calidad lo permita. team-verify siempre usa al menos sonnet.
4. El nivel de riesgo escala la revisión. Los cambios sensibles a la seguridad o de más de 20 archivos deben incluir security-reviewer + code-reviewer (opus) en team-verify.

Criterios de Entrada/Salida de Etapa

• team-plan
  • Entrada: La invocación del equipo se analiza y comienza la orquestación.
  • Agentes: explore escanea el código base, planner crea el grafo de tareas, opcionalmente analyst/architect para tareas complejas.
  • Salida: la descomposición está completa y se prepara un grafo de tareas ejecutable.
• team-prd
  • Entrada: el alcance es ambiguo o faltan criterios de aceptación.
  • Agentes: analyst extrae requisitos, opcionalmente critic.
  • Salida: los criterios de aceptación y los límites son explícitos.
• team-exec
  • Entrada: la asignación de la lista de tareas y la generación de trabajadores están completas.
  • Agentes: trabajadores generados como el tipo de especialista apropiado por subtarea (ver tabla de enrutamiento).
  • Salida: las tareas de ejecución alcanzan un estado terminal para el pase actual.
• team-verify
  • Entrada: el pase de ejecución finaliza.
  • Agentes: verifier + revisores apropiados para la tarea (ver tabla de enrutamiento).
  • Salida (éxito): las puertas de verificación pasan sin necesidad de seguimiento.
  • Salida (fallo): se generan tareas de corrección y el control pasa a team-fix.
• team-fix
  • Entrada: la verificación encontró defectos/regresiones/criterios incompletos.
  • Agentes: executor/debugger según el tipo de defecto.
  • Salida: las correcciones están completas y el flujo regresa a team-exec luego team-verify.

Bucle de Verificar/Corregir y Condiciones de Parada

Continúa team-exec -> team-verify -> team-fix hasta que:

1. la verificación pase y no queden tareas de corrección requeridas, o
2. el trabajo alcance un resultado terminal explícito de bloqueado/fallido con evidencia.

team-fix está limitado por intentos máximos. Si los intentos de corrección exceden el límite configurado, se transiciona a failed terminal (sin bucle infinito).

Convención de Entrega entre Etapas

Al transicionar entre etapas, el contexto importante — decisiones tomadas, alternativas rechazadas, riesgos identificados — solo existe en el historial de conversación del líder. Si el contexto del líder se compacta o los agentes se reinician, este conocimiento se pierde.

Cada etapa que finaliza DEBE producir un documento de entrega antes de transicionar.

El líder escribe las entregas en .omc/handoffs/<nombre-etapa>.md.

Formato de Entrega

## Entrega: <etapa-actual> → <etapa-siguiente>

- **Decidido**: [decisiones clave tomadas en esta etapa]
- **Rechazado**: [alternativas consideradas y por qué fueron rechazadas]
- **Riesgos**: [riesgos identificados para la siguiente etapa]
- **Archivos**: [archivos clave creados o modificados]
- **Restante**: [elementos que la siguiente etapa debe manejar]

Reglas de Entrega

1. El líder lee la entrega anterior ANTES de generar los agentes de la siguiente etapa. El contenido de la entrega se incluye en los mensajes de generación de los agentes de la siguiente etapa, asegurando que los agentes comiencen con contexto completo.
2. Las entregas se acumulan. La etapa de verificación puede leer todas las entregas anteriores (plan → prd → exec) para obtener el historial completo de decisiones.
3. En caso de cancelación del equipo, las entregas sobreviven en .omc/handoffs/ para reanudar la sesión. No son eliminadas por la limpieza nativa del equipo de Claude Code; no existe ninguna llamada TeamDelete en Claude Code 2.1.178+.
4. Las entregas son ligeras. Máximo 10-20 líneas. Capturan decisiones y fundamentos, no especificaciones completas (estas viven en archivos entregables como DESIGN.md).

Ejemplo

## Entrega: team-plan → team-exec

- **Decidido**: Arquitectura de microservicios con 3 servicios (auth, api, worker). PostgreSQL para persistencia. JWT para tokens de autenticación.
- **Rechazado**: Monolito (problemas de escalabilidad), MongoDB (el equipo tiene experiencia en SQL), cookies de sesión (diseño API-first).
- **Riesgos**: El servicio worker necesita Redis para la cola de trabajos — aún no aprovisionado. El servicio auth no tiene límite de tasa en el diseño inicial.
- **Archivos**: DESIGN.md, TEST_STRATEGY.md
- **Restante**: Scripts de migración de base de datos, configuración de pipeline CI/CD, aprovisionamiento de Redis.

Semántica de Reanudación y Cancelación

• Reanudar: reiniciar desde la última etapa no terminal usando el estado de la etapa + el estado vivo de la tarea. Leer .omc/handoffs/ para recuperar el contexto de transición de etapa.
• Cancelar: /oh-my-claudecode:cancel solicita el apagado de los compañeros, espera respuestas (mejor esfuerzo), marca la fase cancelled con active=false, captura metadatos de cancelación, luego elimina los recursos del equipo y limpia/conserva el estado del equipo según la política. Los archivos de entrega en .omc/handoffs/ se conservan para una posible reanudación.
• Los estados terminales son complete, failed y cancelled.

Puerta de compatibilidad con psmux tmux para Windows

En Windows nativo, no digas a los usuarios que /team requiere WSL o que tmux no está disponible hasta que se haya verificado el binario compatible con tmux. psmux nativo instala un comando compatible con tmux (a menudo tmux / tmux.cmd) y es un multiplexor de Team compatible.

Antes de bloquear o recurrir a una alternativa en Windows:

1. Comprueba tmux -V (o el equivalente de la plataforma, como where tmux seguido de tmux -V).
2. Trata un tmux -V exitoso respaldado por psmux como tmux disponible.
3. Si psmux/tmux está disponible, continúa con el flujo normal de Team; no emitas orientación que requiera WSL.
4. Solo cuando no haya un binario compatible con tmux disponible, dí al usuario que instale psmux para soporte nativo de Windows o use WSL2 como alternativa.

Flujo de Trabajo

Fase 1: Analizar Entrada

• Extraer N (cantidad de agentes), validar 1-20
• Extraer tipo-agente, validar que se asigne a un subagente OMC conocido
• Extraer la descripción de la tarea

Fase 2: Analizar y Descomponer

Usar explore o architect (a través de MCP o agente) para analizar el código base y dividir la tarea en N subtareas:

• Cada subtarea debe tener alcance de archivo o alcance de módulo para evitar conflictos
• Las subtareas deben ser independientes o tener un orden de dependencia claro
• Cada subtarea n

…

[truncado para traducción]