0xVoidw/asignador-de-subagentes

Asignador de Subagentes

Convierte un plan.md en una tabla de trabajo ejecutable: quién hace qué, con qué modelo, cuánto esfuerzo de pensamiento, y cómo escalar si falla.

El principio para ahorrar costos es simple: la mayor parte del trabajo en un plan consiste en leer archivos, buscar código, ejecutar pruebas y modificar código según especificaciones; esto no requiere el modelo más caro. Los modelos caros solo deben usarse en los pocos casos que realmente requieren capacidad de juicio. Esta habilidad se encarga de separar ambos tipos de tareas.

Entrada

1. Ruta del plan.md. Si no se proporciona, busca plan.md / PLAN.md / PLANS.md en el directorio actual. Si no lo encuentra, pregunta.
2. Plataforma objetivo: claude (Claude Code), codex (OpenAI Codex) o both. Si no se especifica, se determina según el entorno de ejecución actual; si no se puede determinar, pregunta una vez.
3. Orientación (opcional): ahorro, equilibrado (por defecto), seguro. Solo afecta el paso 4 cuando haya dudas sobre qué dirección tomar.

Una vez determinada la plataforma, lee los archivos de referencia correspondientes, que contienen los nombres específicos de modelos, proporciones de precios y niveles de effort:

• Claude → references/claude.md
• Codex → references/codex.md
• both → lee ambos; en la salida se presentan dos configuraciones lado a lado

Los nombres de modelos y precios pueden quedar obsoletos. Los archivos de referencia son la única fuente de información; no uses nombres de modelos de memoria.

Proceso

1. Leer el plan y dividir en unidades de trabajo

Sigue la propia división de pasos del plan.md, solo ajusta en dos casos:

• Dividir: Un paso que combina "mucha lectura/búsqueda" con "tomar decisiones/modificar código". Separa la parte de lectura para asignarla a un subagente barato, que solo devuelva un resumen.
• Fusionar: Varios pasos pequeños consecutivos que modifican los mismos archivos y necesitan el mismo contexto. Combínalos en una sola tarea para evitar recargar el contexto innecesariamente.

No dividas en exceso. Cada subagente tiene un costo de inicio (releer contexto, escribir instrucciones de transferencia). Las tareas que se completan en minutos deben ser ejecutadas directamente por el agente principal; márcalo en el documento como "Ejecutado directamente por el agente principal".

2. Etiquetar cada tarea con cinco marcadores

Marcador	Pregunta	Valor
Claridad	¿Las especificaciones ya están definidas y solo hay que seguirlas?	Clara / Parcial / Abierta
Coste de error	Si se equivoca, ¿es fácil de detectar y revertir?	Bajo / Medio / Alto
Verificable	¿Hay tests, builds, linters, scripts que puedan juzgar automáticamente si está bien?	Sí / Se puede añadir / No
Volumen de lectura	¿Cuánto material necesita leer antes de empezar?	Poco / Mucho
Impacto	¿El cambio es local, entre módulos, o afecta a la arquitectura?	Local / Entre módulos / Arquitectura

Si el plan.md no lo aclara, juzga según el caso más probable y anótalo en la columna "Suposiciones" de la salida; no te detengas a preguntar por cada punto.

3. Mapear a cuatro niveles

Los modelos específicos de cada plataforma están en los archivos de referencia; aquí solo se definen los niveles:

Nivel	Uso	Tareas típicas
T0 Ligero	Clara + bajo coste + resultado verificable a simple vista	Buscar archivos, leer logs, ejecutar tests e informar, clasificar, extraer, resumir
T1 Estándar	Clara + local + verificable	Implementar funciones según especificaciones, corregir bugs localizados, escribir tests, documentación, recrear UI
T2 Principal	Parcialmente clara, o entre módulos, o requiere juicio para depuración	Funcionalidades multi-archivo, depurar bugs de causa desconocida, revisión de código, integrar resultados de subagentes
T3 Premium	Abierta + nivel de arquitectura, o coste de error alto y no verificable automáticamente	Decisiones arquitectónicas, planificación de refactorizaciones grandes, resolver conflictos con múltiples restricciones, dirigir múltiples subagentes

Orden de decisión: primero asume T1, luego mira si hay razones para bajar o subir.

• Razones para bajar a T0: La tarea es esencialmente "encontrar e informar", no produce código que deba fusionarse.
• Razones para subir a T2: La claridad no es "clara", o el impacto no es "local".
• Razones para subir a T3: Debe cumplir simultáneamente "abierta o nivel de arquitectura" y "equivocarse tiene un coste alto". Si solo cumple una, usa T2 con effort alto.

En un plan normal, suele haber de 0 a 2 tareas T3. Si la mitad de las tareas resultan ser T3, vuelve a revisar la división: probablemente estás mezclando "lectura" con "juicio".

4. Determinar el esfuerzo de pensamiento

effort es un ajuste más fino que cambiar de modelo; ajústalo primero.

• Por defecto: Usa siempre el valor inicial por defecto de ese nivel en el archivo de referencia.
• Verificable = Sí: Mantén el valor inicial, o incluso baja un escalón. Cuando el modelo puede autoverificarse con tests, aumentar el effort tiene poco beneficio.
• Verificable = No y coste de error ≥ medio: Sube un escalón.
• Alguien espera resultados en tiempo real: Baja un escalón, prioriza la velocidad.
• Orientación ahorro: Cuando dudes, elige el valor más bajo. Orientación seguro: Elige el valor más alto.

Una vez que se supera high, subir el effort adicional suele costar casi lo mismo que cambiar directamente al modelo del siguiente nivel con effort bajo. Por lo tanto, la escalera de mejora es:

1. Primero, añade un medio de verificación (dale un comando de test o comprobación que pueda ejecutar)
2. Sube el effort un escalón, como máximo hasta high
3. Cambia al modelo del siguiente nivel, empezando desde el valor inicial más bajo de ese nivel

Codex T0 es una excepción; mantiene buena relación calidad-precio incluso con effort alto. Consulta references/codex.md para más detalles.

5. Protección de calidad

Ahorrar costos no debe hacerse a costa de rehacer el trabajo, que es más caro que usar el modelo correcto desde el principio. Las siguientes medidas garantizan que "la calidad no cambie de forma apreciable":

• Cada tarea debe tener un criterio de finalización. Si se puede escribir como comando, escríbelo (pytest tests/x, npm run build). Si no se puede escribir un criterio de finalización, sube el nivel de la tarea un escalón.
• La modificación de código y las decisiones críticas se quedan en T1 o superior. T0 solo lee y escribe, pero no en la rama principal (informes, listas).
• Después de que un modelo barato termine, un modelo un nivel superior revisa el diff. Revisar el diff solo consume los tokens de los cambios, es muy barato y detecta la mayoría de los problemas. Inclúyelo en la tabla de asignación como una tarea de revisión independiente, al final de cada fase.
• Los subagentes solo devuelven conclusiones. En la descripción del rol, especifica el formato de retorno y un límite de longitud (por ejemplo, "resumen de no más de 200 palabras + lista de rutas de archivos relevantes") para evitar que las salidas largas llenen el contexto del agente principal.

6. Orden de ejecución

• Las tareas independientes se marcan como paralelizables.
• Siempre que sea posible, agrupa las tareas que usan el mismo modelo en la misma fase, y cambia de modelo en los puntos de ruptura naturales entre fases. Cambiar de modelo con frecuencia durante la ejecución pierde la caché, lo que equivale a pagar de nuevo el costo del contexto.
• Las consideraciones específicas de cada plataforma (pertenencia de caché, umbrales de aumento de precio por contexto largo, etc.) están en los archivos de referencia; si se aplican, escríbelas en la sección "Consideraciones" de la salida.

Salida

Escribe plan.dispatch.md en el mismo directorio que plan.md, con la siguiente estructura. Si hay muchas tareas, la tabla debe incluir todas; las tarjetas de roles solo se escriben para las tareas de subagentes.

# Asignación de Subagentes: <Nombre del plan>

Fuente: <ruta del plan.md>　Plataforma: <claude / codex / both>　Orientación: <ahorro / equilibrado / seguro>

## Resumen

| # | Tarea | Ejecutor | Nivel | Modelo | effort | Dependencias | Paralelizable |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | … | Explorador | T0 | … | … | Ninguna | Con 2 |

Distribución de niveles: T0 ×n, T1 ×n, T2 ×n, T3 ×n
Agente principal: <Modelo> / <effort>, responsable de <coordinación, integración, validación final, etc.>

## Fases de ejecución

### Fase 1: <Nombre> (Modelo: …)
- Tareas 1, 2 en paralelo
- Revisión al final de la fase: <Quién revisa, qué revisa>

## Tarjetas de roles

### Tarea 1: <Nombre>
- **Rol**: <Descripción en una frase, ej. "Explorador de solo lectura: localiza todas las posiciones que usan la interfaz antigua">
- **Modelo / effort**: … / …
- **Objetivo**: …
- **Entrada**: <Archivos, directorios, mensajes de error a leer>
- **Restricciones**: <Qué no debe modificar, qué normas debe seguir>
- **Criterio de finalización**: <Comando o estado comprobable>
- **Formato de retorno**: <Contenido y límite de longitud>
- **Escalera de mejora**: Añadir verificación → subir effort a … → cambiar a … / …
- **Justificación de la elección**: <Una frase, correspondiente a los cinco marcadores>

## Suposiciones y consideraciones
- <Puntos no aclarados en plan.md, inferidos por esta habilidad>
- <Trampas de costos relacionadas con la plataforma>

## Ahorro estimado
Estimación aproximada con respecto a "usar la configuración predeterminada del modelo principal para todo": <ej. "Aproximadamente la mitad de las tareas se reducen a T0/T1, el costo unitario de esa parte se reduce entre 1/2 y 1/20">

Los campos "Objetivo", "Entrada", "Restricciones" y "Criterio de finalización" de la tarjeta de rol son las instrucciones que se pueden pegar directamente al subagente; escríbelas para que se entiendan de forma independiente, ya que el subagente no verá el resto del plan.md.

"Ahorro estimado" solo da el orden de magnitud y la base; no inventes porcentajes exactos. El consumo real depende de la tarea en sí; se recomienda al usuario que revise las estadísticas de uso después de ejecutarlo y ajuste la configuración en consecuencia.

Ejemplo

En el plan.md hay un paso:

3. Reemplazar todas las instancias de oldLogger por newLogger en utils/, ten en cuenta que algunos lugares pasan un formatter personalizado

Procesamiento: Este paso mezcla "encontrar todos los puntos de llamada" (mucha lectura, solo lectura) con "reemplazar y manejar las excepciones de formatter" (hay que modificar código, hay excepciones que requieren juicio). Se divide en dos tareas:

#	Tarea	Ejecutor	Nivel	effort	Razón
3a	Listar todos los puntos de llamada a oldLogger, marcando los que tienen formatter personalizado	Explorador	T0	Valor inicial	Solo lectura; si omite alguno, lo detectará el grep de 3b
3b	Reemplazar según la lista, adaptar cada excepción de formatter individualmente	Implementador	T1	Valor inicial	Especificación clara; el criterio de finalización es que grep -r oldLogger utils/ no devuelva nada y los tests pasen

Si no hay tests que cubran el comportamiento del formatter, el effort de 3b sube un escalón y se anota en "Suposiciones y consideraciones".