oil-oil/codex-team-mode

Modo Equipo

Lidera la tarea en el hilo principal. Usa el conjunto más pequeño útil de subagentes para aislar trabajo ruidoso, reducir el costoso contexto del agente principal, ejecutar trabajo independiente en paralelo u obtener una revisión fresca. No conviertas los roles en una tubería obligatoria.

Puerta de Despacho

Cada llamada a spawn_agent debe pasar explícitamente agent_type como exactamente uno de Explorer, Executor, Complex Executor o Reviewer.

• Nunca omitas agent_type y nunca pases default. El perfil default es un guardián de despacho con cierre seguro, no un agente funcional.
• Nunca uses task_name para seleccionar un perfil; solo etiqueta el hilo hijo.
• Si el perfil personalizado previsto no está disponible, mantén el trabajo en el hilo principal o repara los perfiles. No uses un hijo genérico en silencio.
• Si un hijo devuelve el mensaje del guardián de despacho o su traza muestra default / subagent/unknown, rechaza su salida y reengendra solo después de seleccionar explícitamente el perfil personalizado previsto.

Lee references/custom-agents.md solo al instalar, reparar o verificar los cuatro perfiles funcionales y el guardián default. La autoprueba de incorporación controlada descrita allí es la única vez que el Modo Equipo omite deliberadamente agent_type.

Incorporación Única

No inspecciones archivos de agente, cargues instrucciones de incorporación ni repitas explicaciones de configuración durante el enrutamiento normal del Modo Equipo. Trata las opciones spawn_agent.agent_type activas y sus descripciones como evidencia de disponibilidad en tiempo de ejecución. Cuando los cuatro perfiles funcionales estén disponibles y default esté descrito como el guardián de despacho, omite la incorporación sin mencionarla.

Solo lee references/custom-agents.md e inicia la incorporación cuando un perfil requerido o el guardián no estén disponibles, o cuando el usuario pida explícitamente instalar, reparar, verificar, mover, deshabilitar o personalizarlos. Obtén autorización antes de escribir configuraciones personales o del proyecto. Después de una configuración o reparación exitosa, dile al usuario una vez qué se instaló, qué modelos están asignados, que el guardián afecta los despachos omitidos/predeterminados de subagentes en su ámbito de instalación, cuándo se requiere un reinicio o una nueva tarea, y cómo deshabilitar o restaurar solo el guardián sin eliminar los cuatro perfiles funcionales.

Reglas Requeridas

• Cuando esta skill se active, envía inmediatamente un breve comentario de actualización en el idioma del usuario, prefijado con 👾. Para español, di 👾 Modo equipo activado.; traduce naturalmente para otros idiomas. Anúncialo una vez por tarea, no antes de cada llamada al subagente.
• Activar el Modo Equipo no requiere engendrar ningún subagente. Mantén el trabajo claro, corto y de bajo riesgo en el hilo principal cuando la delegación o la revisión independiente cuesten más de lo que aportan. No lances un Executor o Reviewer solo para completar una secuencia de roles.
• Antes de cada engendramiento, identifica un beneficio material: paralelismo útil, aislamiento de contexto, ejecución acotada de menor costo o juicio independiente. Cuenta el informe, la inspección, el retrabajo y la espera como costo de coordinación. Una solicitud explícita de Modo Equipo activa esta guía de enrutamiento; no hace que un engendramiento valga la pena por sí mismo.
• Mantén todo el enrutamiento y la difusión en el hilo principal. Bajo el Modo Equipo estándar, los hijos nunca engendran descendientes; devuelven evidencia, artefactos o bloqueadores al padre. Trata una solicitud explícita del usuario de delegación recursiva como una expansión de alcance separada con su propio permiso, profundidad y decisión de uso.
• Usa fork_turns="none" por defecto y siempre para un nuevo Reviewer.
• Mantén las decisiones no resueltas de intención del usuario, producto, editorial, arquitectura y seguridad, así como la aceptación final, en el hilo principal.
• Mantén un escritor por artefacto compartido, árbol de trabajo o sistema mutable. Los escritores paralelos requieren objetivos aislados o propiedad disjunta y estable.
• Inspecciona los artefactos reales, fuentes, diferencias y salida de verificación antes de aceptar trabajo delegado.
• Si un hijo da error, se agota el tiempo o se interrumpe, inspecciona los artefactos compartidos y la evidencia de la traza antes de reintentar. Reintenta un fallo transitorio como máximo una vez y solo cuando no exista un resultado utilizable; de lo contrario, recupera en el hilo principal o reajusta el alcance del trabajo restante.
• Trata el modo de permiso activo de la tarea padre como el permiso efectivo del hijo. No infieras aislamiento de solo lectura del TOML solo; usa la incorporación o la verificación de diagnóstico en la referencia cuando los permisos necesiten confirmación.

Cuando el usuario pida evaluar el Modo Equipo en sí mismo, comparar modelos o esfuerzo de razonamiento, o medir si la delegación valió la pena, lee references/evaluation.md antes de diseñar la prueba.

Contrato de Despacho

Antes de cada engendramiento, haz que el informe sea breve y autocontenido con estos campos etiquetados:

• Resultado: el resultado finalizable de forma independiente que el hijo debe devolver.
• Beneficio: la ventaja material sobre mantener este fragmento en el hilo principal.
• Fuentes: cada ruta, URL, conjunto de datos o artefacto sin procesar requerido para el trabajo fáctico.
• Alcance: lecturas o escrituras permitidas, propiedad, exclusiones y autoridad de acción externa.
• Verificaciones: criterios de aceptación y validación que el hijo posee.
• Parar cuando: la finalización acotada, el bloqueador o el umbral de evidencia que termina el turno.
• Devolver: el informe conciso o formato de artefacto esperado por el padre.

No engendres mientras falten Resultado, Beneficio, Fuentes requeridas, Verificaciones o Parar cuando. Mantén el fragmento en el hilo principal cuando no sea finalizable de forma independiente o la ganancia esperada no supere el informe, la espera, la inspección y el posible retrabajo.

Para un Reviewer, también nombra un Riesgo no resuelto concreto, la Evidencia exacta a inspeccionar, las Verificaciones ya superadas y No repetir. Pide hallazgos desde ese paquete primero y requiere un veredicto parcial utilizable si la condición de parada llega antes de la revisión exhaustiva.

Enruta el Trabajo

• Explorer (Luna Medium): úsalo para descubrimiento no trivial de solo lectura. Da a Exploradores separados fragmentos de evidencia independientes y no repitas su trabajo en el hilo principal.
• Executor (Luna High): úsalo para trabajo claro, acotado y de bajo riesgo con verificaciones deterministas. Mantén el trabajo en el hilo principal cuando el costo de transferencia sea mayor que hacerlo directamente.
• Complex Executor (Terra High): úsalo para implementación convencional sustancial después de que el hilo principal haya fijado la arquitectura, el alcance y las verificaciones. El hilo principal aún inspecciona y acepta el resultado.
• Hilo principal: mantén el fragmento crítico cuando necesite arquitectura novedosa, verificación débil o visual, diseño de exportación/compilador, juicio de seguridad o reversión, o cuando un falso éxito plausible sería costoso.
• Reviewer (Sol High): úsalo solo para un riesgo no resuelto concreto que se beneficie de un juicio independiente fresco. No hagas de la revisión un segundo pase automático.

Después del descubrimiento, deja que el hilo principal elija si continuar directamente o delegar. Delega solo cuando la ejecución acotada, el aislamiento de contexto, el menor costo, el paralelismo útil o el juicio independiente creen valor claro.

Coordina el Trabajo

• Comienza con el número mínimo útil de agentes. Paraleliza solo exploración, análisis, pruebas, triaje, producción o revisión genuinamente independientes; no crees trabajo duplicado solo para mantener ocupados a los agentes.
• Antes de la ejecución, expresa claramente cuál debería ser el resultado, qué puede tocarse, qué debe permanecer sin cambios y cómo se verificará la finalización. Revisa estos requisitos si nueva evidencia entra en conflicto con ellos.
• Verifica en proporción al riesgo. Usa revisión independiente para resultados complejos, consecuentes o difíciles de verificar, en lugar de para cada tarea.
• Reutiliza las verificaciones superadas como evidencia. No pidas a otro agente que repita una validación amplia a menos que la integridad o relevancia de esas verificaciones sea en sí misma el riesgo no resuelto.

Contexto y Reutilización

• Dale a cada nuevo subagente un informe compacto y autocontenido que contenga solo el objetivo, las fuentes o rutas relevantes, el alcance, la autoridad, las exclusiones, el resultado previsto, las verificaciones requeridas y el formato de devolución. Nunca copies credenciales en él.
• Con fork_turns="none", asume que el hijo no sabe nada de la conversación del padre. Nombra cada artefacto fuente requerido para afirmaciones fácticas; si falta una fuente, proporciona su ruta, limita al hijo a recopilar esa evidencia o mantén el fragmento dependiente de la fuente en el hilo principal.
• Reutiliza un Explorer o executor existente cuando el nuevo trabajo pertenezca a la misma tarea, tema, área de negocio, subsistema, artefacto o flujo de trabajo y su contexto previo siga siendo útil. Envía solo el nuevo objetivo y las restricciones cambiadas.
• Comienza de nuevo cuando el contexto previo esté desactualizado o ruidoso, el rol o la autoridad cambien, o el juicio independiente sea importante.
• Reutiliza un Reviewer solo para aclarar su informe existente. Usa un Reviewer nuevo para una revisión nueva o para verificar trabajo revisado.
• No le des a un Explorer una conclusión esperada. No le digas a un Reviewer el debate previo, el autor, los hallazgos sospechados o el veredicto deseado.

Maneja los Hallazgos

• Valida los hallazgos contra las fuentes subyacentes, el artefacto y el resultado previsto antes de actuar.
• Deja que el hilo principal aplique las reparaciones aceptadas directamente o las delegue según el alcance, contexto, costo y riesgo.
• Cuando la evaluación de riesgo requiera revisión independiente después de reparaciones consecuentes, usa un Reviewer nuevo con solo el artefacto actualizado y requisitos neutrales.
• Si un Reviewer cruza su condición Parar cuando sin una devolución utilizable, solicita un veredicto parcial una vez, luego interrúmpelo. Inspecciona la traza y la evidencia existente; no inicies otro Reviewer automáticamente.

Inspecciona el Uso Local

Cuando el usuario pregunte por el consumo de modelo o subagente, ejecuta python3 scripts/usage_by_model.py. Para la tarea activa usa --task-id current --by-agent --by-session; para un historial más amplio usa --days N o --all, con --json cuando la salida estructurada sea útil. Informa los tokens procesados más la entrada no almacenada en caché, la entrada en caché, la salida, la salida de razonamiento y los créditos estimados; no ocultes los totales de tokens detrás de los créditos. Trata el razonamiento como un subconjunto de la salida y los tokens procesados como entrada más salida, de modo que ni los tokens en caché ni los de razonamiento se cuenten dos veces. Nunca presentes una conversión universal de créditos a tokens: usa la tarjeta de tarifas incluida porque cada modelo y tipo de token tiene una tarifa diferente, y etiqueta el valor observado de tokens procesados por crédito como específico de la carga de trabajo. Este es un diagnóstico bajo demanda, no parte del enrutamiento normal. Informa que los registros locales excluyen sesiones remotas efímeras o no disponibles, los créditos configurados asumen velocidad Estándar, y que /usage de Codex sigue siendo la autoridad para los límites de cuenta.

Barreras de Protección

• Preserva el trabajo no relacionado del usuario y obedece las instrucciones aplicables del proyecto, dominio y herramienta.
• La delegación no expande la autoridad. No confirmes, publiques, despliegues, envíes mensajes, cambies el estado externo ni manejes datos sensibles más allá de la solicitud del usuario.
• Para investigación actual o fáctica, prefiere fuentes primarias, registra fechas relevantes, cita evidencia y distingue hecho de inferencia.
• Mantén la exploración de datos privados limitada y devuelve solo la evidencia mínima necesaria.
• Resuelve afirmaciones conflictivas contra la evidencia más sólida disponible y devuelve un resultado coherente al usuario.