Agent Army (Ejército de Agentes)

¿Qué hace Agent Army (Ejército de Agentes)?

Un marco de ejecución paralela de 2 capas. El Comandante es el modelo de nivel superior — Fable por defecto, u Opus si ese es el modelo de la sesión — y realiza el pensamiento: reconocimiento, composición, briefing, verificación. Orquesta enjambres de modelos subordinados cuyos niveles el usuario elige en el momento del despliegue (ver Nivel de Potencia). Cada agente de la Capa 1 tiene su propio contexto completo (no una porción). Cada uno genera sub-agentes de la Capa 2 debajo de él. El resultado es muchos cerebros independientes ejecutándose a la vez — no un solo cerebro dividido.

Comandante (tú — Fable u Opus, el modelo de la sesión)
 |
 |-- Capa 1: Equipo (de 3 a 50+, cada uno = contexto de 1M, nivel L1 del nivel de potencia)
 |    |-- Agente A (1M) -- Sub-agentes A1, A2, ... (nivel L2)
 |    |-- Agente B (1M) -- Sub-agentes B1, B2, ... (nivel L2)
 |    |-- Agente C (1M) -- Sub-agentes C1, C2, ... (nivel L2)
 |    |-- ... (sin límite)

Enjambre vs. ejército: Un enjambre divide una ventana de contexto entre sub-agentes — un cerebro, dividido. Un ejército le da a cada miembro de la Capa 1 su propia ventana. Esa diferencia es el objetivo principal de este skill.

Cuándo usarlo

• Refactors grandes que abarcan muchos archivos
• Migraciones multi-archivo de color / estilo / nomenclatura / API
• Auditorías amplias de código (seguridad, accesibilidad, rendimiento, código muerto)
• Generación o transformación de contenido por lotes
• Cualquier tarea con 6+ unidades de trabajo independientes que puedan ejecutarse simultáneamente

Cuándo NO usarlo

• Menos de 6 unidades de trabajo independientes — hazlo directamente
• Dependencias secuenciales pesadas donde cada paso necesita la salida del anterior
• Cambios en un solo archivo
• Tareas que necesitan una voz autoral coherente en toda la salida (los agentes paralelos derivan)

Si la tarea no encaja claramente, dilo y propón hacerla directamente en lugar de desplegar un ejército.

1. CADA agente de la Capa 1 DEBE generar 2+ sub-agentes. Sin excepciones. Si estás a punto de desplegar un agente L1 sin sub-agentes, DETENTE y reestructura.
2. NUNCA reduzcas silenciosamente el ejército. Cumple con el nivel elegido por el usuario. Si debes desviarte, dilo en voz alta y explica por qué. 2b. NUNCA degradar modelos silenciosamente. Pasa model: explícitamente en cada llamada de Agente al nivel de potencia elegido por el usuario. Omitirlo hereda el modelo de la sesión — eso es una factura silenciosa de Max Power.
3. Las instrucciones de despliegue de sub-agentes van DENTRO del briefing de la Capa 1. Si faltan, los sub-agentes nunca se crearán.
4. Reporta a medida que los agentes completan: [Agente N/M completado] nombre: X archivos modificados, Y banderas.
5. Muestra el plan del ejército y pasa la Puerta de Despliegue antes de desplegar (Modo Completo). El Modo Rápido compone el plan internamente pero aún pasa la Puerta.
6. Después de cada oleada: ejecuta la compilación Y la verificación de finalización fantasma (ver Verificar). Un informe verde de un agente es una afirmación, no una prueba.
7. "Continúa" / "no te detengas" = modo continuo: lanza un nuevo agente en cuanto uno termine. No esperes, no vuelvas a preguntar.

Tamaño del Ejército

Confirma un nivel antes de comenzar. Presenta esta tabla:

| Nivel        | Agentes L1 | Total con Sub-agentes | Est. Tokens |
|--------------|------------|-----------------------|-------------|
| Conservador  | 3          | ~9                    | ~200-500K   |
| Estándar     | 5-10       | ~15-30                | ~500K-1.5M  |
| Agresivo     | 10-20      | ~30-60                | ~1.5-4M     |
| Máximo       | 20-50+     | ~60-100+              | ~4M+        |
| Personalizado| tú eliges  | tú eliges             | varía       |

Por defecto, usa Estándar en "solo hazlo." Después del reconocimiento (Paso 3), recomienda un número específico basado en lo que encontraste — por ejemplo, "35 archivos en 6 dominios → Agresivo: 8 agentes L1, 2-3 sub-agentes cada uno (~22 total, ~2M tokens). ¿Ajustar?" Las estimaciones de tokens son aproximadas y escalan con la complejidad de la tarea.

Nivel de Potencia

El tamaño define cuántos agentes; la potencia define qué modelos. Pregunta ambas cosas en una sola pregunta (AskUserQuestion funciona bien — tamaño y potencia como dos preguntas en una llamada). Omite preguntar si el usuario ya nombró un nivel de potencia o modelos explícitos.

| Nivel de Potencia | Comandante            | Capa 1 | Capa 2 | Mejor para                                      |
|-------------------|-----------------------|--------|--------|-------------------------------------------------|
| Max Power         | Fable/Opus (sesión)   | Opus   | Opus   | Refactors difíciles, migraciones críticas de corrección|
| Heavy (recomendado)| Fable/Opus (sesión)  | Opus   | Sonnet | La mayoría de las tareas grandes — orquestación inteligente, ejecución rápida|
| Balanced          | Fable/Opus (sesión)   | Sonnet | Sonnet | Migraciones mecánicas con patrones claros       |
| Economy           | Fable/Opus (sesión)   | Sonnet | Haiku  | Alto volumen, buscar/reemplazar muy simple       |

Reglas:

• El Comandante siempre es el modelo de la sesión — Fable u Opus, la elección del usuario — y nunca se delega. Si la sesión está ejecutando Sonnet o Haiku, dile al usuario que cambie (/model o claude --model fable) antes de desplegar: la calidad del comandante es el techo de la calidad del ejército.
• Pasa el modelo explícitamente en cada llamada de Agente: model: "<nivel L1>" para los miembros del equipo; los briefings L1 instruyen model: "<nivel L2>" para los sub-agentes.
• La escalación por agente está permitida en cualquier nivel de potencia: un archivo pesado o enredado (1000+ líneas, lógica compleja) puede subir de nivel a ese sub-agente. Anota las escalaciones en el plan del ejército.
• Las oleadas de auditoría se ejecutan en Opus independientemente del nivel de potencia — ojos nuevos y más fuertes en el trabajo de los ejecutores. Las oleadas de notificación pueden bajar a Haiku.

Protocolo

Modo: Si el alcance ya es concreto (rutas de archivo, cambios exactos, nivel), salta al Paso 3 (Modo Rápido). De lo contrario, comienza en el Paso 1 (Modo Completo).

Paso 1: Toma de Requisitos (Modo Completo)

Confirma en una línea si el usuario ya dio contexto: "Objetivo: [X]. Alcance: [Y]. Nivel: [Z]. Potencia: [P]. Comenzando." De lo contrario, pregunta por: objetivo (una frase), alcance (archivos/dirs/"todo"), restricciones (no toques X, cumple Y), nivel y nivel de potencia.

Paso 2: Punto de Control Git

1. git status — advierte sobre cambios no confirmados, ofrece hacer stash o commit primero.
2. git checkout -b agent-army/checkpoint-{timestamp} luego vuelve atrás. Este es el punto de reversión.
3. ¿No hay repositorio git? Advierte que no hay red de seguridad y obtén confirmación explícita.

Paso 3: Reconocimiento

1. Grep / Glob / Leer para encontrar todos los archivos afectados.
2. Cuenta las unidades de trabajo.
3. wc -l cada archivo. Marca archivos de 500+ líneas como pesados → asigna en solitario.
4. Clasifica en dominios (por directorio, gráfico de importaciones, tipo de archivo, patrón de nomenclatura).
5. Identifica dependencias compartidas — archivos fundacionales importados entre dominios. Maneja estos primero (Paso 5).
6. Identifica el comando de compilación (package.json, Makefile, etc.).

Salida: Archivos: N | Pesados: [lista] | Dominios: [lista] | Dep. compartidas: [lista] | Cmd compilación: [cmd]

Paso 4: Composición

1. Agente Fundacional para dependencias compartidas — se ejecuta antes de la oleada paralela para que los dependientes no entren en conflicto.
2. Capa 1: un agente por dominio; divide dominios grandes entre varios agentes.
3. Capa 2: 2+ sub-agentes por agente L1, asignados por carga de archivos ponderada, no por cantidad de archivos:
   • Pequeño (<200 líneas): 2-3 por sub-agente
   • Medio (200-500): 1-2 por sub-agente
   • Pesado (500+): 1 por sub-agente, en solitario
4. Nombra cada agente. Asigna cada archivo a exactamente un sub-agente — sin superposiciones, sin huecos.

Genera la salida del plan del ejército. Modo Completo: pausa para "¿Proceder?" Modo Rápido: resumen de una línea, luego despliegue.

Puerta de Despliegue

Genera esta lista de verificación en tu respuesta antes de desplegar. No la verifiques mentalmente — escríbela.

PUERTA DE DESPLIEGUE:
[ ] Cada briefing L1 contiene "DEBES generar N sub-agentes"
[ ] Cada sub-agente está nombrado con archivos específicos asignados
[ ] Cada archivo pertenece a exactamente un sub-agente (sin superposición, sin hueco)
[ ] Los briefings L1 incluyen instrucciones completas de despliegue de sub-agentes
[ ] El nivel coincide con la selección del usuario
[ ] Nivel de potencia establecido: model: "<nivel L1>" en cada llamada L1; nivel L2 + escalaciones en cada briefing

Todos deben pasar. Cualquier FALLO → corrige el plan antes de desplegar.

Paso 5: Despliegue

1. Agente Fundacional primero (si lo hay), al nivel L1. Espera a que termine.
2. Lanza TODOS los agentes de la Capa 1 en paralelo — run_in_background: true y model: "<nivel L1>" en cada llamada, en un solo mensaje.
3. Cada agente L1 genera sus sub-agentes L2 en paralelo (según su briefing).
4. Reporta cada finalización: [Agente N/M completado] nombre: resultados.

Paso 6: Verificar

1. Re-examinar — vuelve a ejecutar las búsquedas del Paso 3 para violaciones restantes.
2. Verificación de finalización fantasma — ejecuta git diff --stat y cruza referencias con los informes de los agentes. Cualquier agente que reportó "COMPLETADO, N archivos modificados" sin un diff coincidente mintió o no operó — vuelve a despacharlo. Confía en el diff, no en el informe.
3. Compilación — ejecuta el comando de compilación. Registra ÉXITO/FALLO.
4. Resuelve las banderas entre equipos de los informes.
5. Genera el informe del ejército:

Agentes: N | Archivos modificados: N (confirmado por diff) | Omitidos: N | Compilación: ÉXITO/FALLO
Banderas: [lista] | Finalizaciones fantasma atrapadas: N | Reversión: git checkout agent-army/checkpoint-{timestamp}

Oleadas

Cada oleada es un ejército nuevo, más pequeño y especializado de manera diferente. Pausa para la aprobación del usuario antes de cada una. Máximo 4 oleadas.

Oleada	Nombre	Disparador	Propósito
1	Ejecutar	siempre	hacer los cambios
2	Auditar	compilación falla, violaciones restantes, 20+ archivos o banderas > 0	agentes nuevos revisan la Oleada 1 para corrección/casos extremos
3	Propagar	los cambios tocan APIs/tipos/interfaces; tests o docs referencian patrones antiguos	actualizar tests, docs, configuraciones, llamadores posteriores
4	Notificar	el usuario opta	redactar descripción de PR, changelog, resumen de Slack

El informe de cada oleada es el reconocimiento de la siguiente. Después de cada una, vuelve a ejecutar Verificar; detente cuando la re-exploración esté limpia y la compilación pase, o después de 4 oleadas.

Reanudar / bloc de notas

Para ejecuciones multi-oleada o interrumpibles, escribe .army-state.md después de la Oleada 1: archivos modificados (confirmados por diff), banderas abiertas, problemas no resueltos, decisiones. Si una ejecución se interrumpe, la siguiente invocación lee este archivo y reanuda desde la última oleada limpia en lugar de reiniciar. Omite para tareas de una sola oleada.

Plantilla de Prompt de la Capa 1

Esto es lo que realmente ven los agentes generados — la sección más importante del skill.

Eres [NOMBRE_AGENTE], especialista en [DOMINIO].

Objetivo: [una frase]
Patrones aprobados: [valores exactos — códigos hex, nombres de clase, formas de API]
Patrones prohibidos: [qué eliminar/evitar]
Tus archivos: [rutas absolutas con recuentos de líneas]
Reglas: [restricciones]. Omite archivos que ya usan patrones aprobados (idempotencia).
Marca problemas fuera de tus archivos en "Banderas para el Comandante" — NO los arregles.

CRÍTICO: DEBES usar la herramienta Agente para generar los sub-agentes listados a continuación. NO
hagas el trabajo tú mismo. NO omitas la generación. Despliega TODOS los sub-agentes en un solo
mensaje con múltiples llamadas a la herramienta Agente, pasando model: "[NIVEL_L2]" en cada llamada
[nota escalaciones: excepto "NOMBRE" que obtiene model: "[nivel superior]"].

Sub-agentes:
- "[NOMBRE]": [archivos con recuentos de líneas]
- "[NOMBRE]": [archivos con recuentos de líneas]

Pasa a cada sub-agente: objetivo, sus archivos, patrones aprobados/prohibidos, reglas,
formato de informe. Después de que todos completen, agrega sus informes y verifica (releyendo
o grep) que no queden patrones prohibidos en tu dominio antes de informar.

Plantilla de Prompt de la Capa 2

Eres [NOMBRE_SUB_AGENTE], trabajando bajo [NOMBRE_MIEMBRO_EQUIPO].

Objetivo: [una frase]
Archivos que posees: [rutas absolutas con recuentos de líneas — toca solo estos]
Patrones aprobados / prohibidos: [valores exactos a usar y eliminar]
Reglas: [restricciones]. Omite archivos ya correctos. Marca problemas fuera de tus archivos —
NO los arregles.

Proceso: lee cada archivo completamente → verifica idempotencia → aplica aprobados, elimina prohibidos
→ releer para confirmar que no queden patrones prohibidos.

Informe: Archivos Modificados (archivo: N reemplazos), Archivos Omitidos (ya correctos),
Banderas para el Comandante, Problemas, Estado (COMPLETADO/PARCIAL/FALLIDO).

Formato de Informe

Cada agente devuelve:

## Informe: [Nombre]
Archivos Modificados:   [archivo: N reemplazos]
Archivos Omitidos:     [archivo: razón]
Banderas para el Comandante: [problema o "Ninguna"]
Problemas:             [problema o "Ninguno"]
Estado:                 COMPLETADO / PARCIAL / FALLIDO

Anti-patrones

Estos son los modos de fallo que este skill existe para prevenir. Si te sorprendes haciendo uno, detente y corrige.

• Despliegue fantasma — un agente L1 hace el trabajo él mismo en lugar de generar sub-agentes. Se pierde toda la ventaja de velocidad. Aplicado por la Regla Obligatoria 1 + la Puerta.
• Finalización fantasma — un agente reporta COMPLETADO sin editar nada. Atrapado por la verificación cruzada git diff --stat, no por confiar en el informe.
• Reducción silenciosa — ejecutar silenciosamente 3 agentes cuando el usuario eligió Agresivo. Siempre muestra las desviaciones.
• Deriva de modelo — omitir model: en las llamadas de Agente, por lo que cada sub-agente hereda silenciosamente el modelo del comandante. El usuario eligió Economy y le facturaron Max Power. Aplicado por la Regla Obligatoria 2b + la Puerta.
• Propiedad superpuesta — dos sub-agentes editando el mismo archivo → conflictos y ediciones perdidas. Aplicado por exactamente-un-propietario en la Puerta.
• Saltar la fundación — tocar dependientes antes de que se actualicen los archivos compartidos → cascada de importaciones rotas. El Agente Fundacional se ejecuta primero.
• Ejército para un trabajo pequeño — 9 agentes para 4 archivos es más lento (gasto general de orquestación) y quema tokens. Ver "Cuándo NO usarlo."

Manejo de Errores

• Sub-agente falla → el agente L1 reintenta sus archivos o genera un reemplazo.
• Agente L1 falla → el Comandante genera un reemplazo con el mismo briefing.
• Falla de compilación → diff contra la rama de punto de control para aislar la rotura, luego ejecuta una oleada de corrección.
• Finalización fantasma → re-despacha los archivos de ese agente a un agente nuevo.
• Idempotencia en re-ejecución → los agentes verifican primero los patrones ya aplicados, por lo que ejecutar el ejército dos veces nunca aplica doble.

Ejemplo trabajado

Usuario

...

[truncado para traducción]