Subagentes escalados para Codex
Coordinador recomendado: gpt-6.1-sol con esfuerzo bajo. Mantén el modelo seleccionado del padre; esta habilidad no lo cambia. El agente principal orquesta: elige el nivel, define los criterios de aceptación, instruye a los trabajadores, verifica las transferencias, clasifica e informa. Nunca edita código de producto. Comienza con informes compactos (máximo 30 líneas), diferencias de alcance y rutas de evidencia; inspecciona más código o ejecuta comprobaciones cuando falte evidencia, esté en disputa o sea insuficiente para el riesgo del nivel D. No repitas mecánicamente comprobaciones en un parche sin cambios.
Los trabajadores ejecutan una etapa asignada y nunca delegan ni invocan esta habilidad. Respeta los permisos del host y el modo de colaboración; el modo Plan no permite implementación ni descubrimiento que produzca mutaciones.
Niveles
Nombra el nivel en la primera línea de progreso. Cualquier etapa puede promoverlo; nunca lo degrades. Al promover, conserva los contadores, usa el presupuesto total del nivel superior y revisa los criterios para cada trabajador afectado. Para D, eleva Descubrir/Validar al menos al rango 3; nunca bajes un rango existente. Realiza el nuevo descubrimiento requerido antes de seguir con la implementación.
| Nivel | Trabajo | Flujo | Rango inicial |
|---|---|---|---|
| A | Edición trivial, totalmente especificada, de bajo riesgo con una comprobación concreta | Implementar; la transferencia reemplaza Validar | 1 |
| B | Cambio claro que se beneficia de la delegación | Implementar → Validar | 1 para ambos |
| C | Error poco claro o función sustancial; predeterminado | Descubrir → Implementar → Validar | 1 para todos |
| D | Autenticación, aislamiento de inquilinos, migraciones, cola/sincronización, cambios en datos de producción | Descubrir → Implementar → Validar | Descubrir/Validar 3; Implementar 1 |
Etapas y comprobaciones
- Criterios de aceptación - padre: define "Hecho significa" antes del envío. A/B derivan comprobaciones y resultados esperados de la solicitud; C/D refinan el borrador después de Descubrir. Implementar y Validar reciben criterios idénticos y la solicitud original.
- Descubrir - C/D: confirma el alcance o reproduce el problema. Sin ediciones de producto; se permiten archivos de repro/prueba explícitamente propiedad. Informa causa/alcance con ubicaciones, evidencia, criterios propuestos y preguntas abiertas. Para descubrimiento de solo lectura, prohíbe ediciones en el repositorio en las instrucciones y verifica el alcance; no inventes una configuración de zona de pruebas por agente.
- Implementar: cambia solo los archivos de propiedad; informa ediciones, comandos, estado de salida y trabajo incompleto.
- Validar - B/C/D: un agente nuevo que no implementó comprueba el parche integrado contra la solicitud, especificaciones y criterios. Sin ediciones en el repositorio ni nuevas pruebas de regresión; propón pruebas faltantes para Implementar. Se permiten informes preliminares y artefactos de prueba normales. Informa evidencia por criterio y áreas no probadas.
Prerrequisitos de prueba prevuelo antes de comprometerse con comandos. Prefiere alternativas factibles solo cuando su cobertura sea equivalente. Nunca sustituyas pruebas unitarias por evidencia de integración, extremo a extremo, visual o de dispositivo requerida solo para obtener PASS. Lleva las comprobaciones obligatorias bloqueadas al resultado final; no asumas que un ejecutor de pruebas en particular pueda ejecutarse en la zona de pruebas. Reintenta fallos ambientales solo después de un remedio concreto.
Descubrir/Implementar devuelve DONE, PARTIAL o BLOCKED. Validar devuelve PASS, FAIL, BLOCKED o INCONCLUSIVE. Presupuestos de tiempo por llamada: A/B 10 minutos; C/D 25 minutos. Al límite, devuelve PARTIAL o INCONCLUSIVE con el trabajo completado, evidencia, comprobaciones pendientes y el siguiente paso.
Escalera y envío
| Rango | Modelo | reasoning_effort |
|---|---|---|
| 1 | gpt-6-luna | medium |
| 2 | gpt-6-luna | medium |
| 3 | gpt-6.1-sol | low |
| 4 | gpt-6.1-sol | medium |
| 5 | gpt-6.1-sol | high |
El rango 2 es un reintento fresco de Luna con evidencia de corrección concreta. Sol low es Ligero en la aplicación, no un rango adicional.
Para una omisión concreta o instrucciones mal leídas, avanza un rango; el rango 2 es el único reintento por omisión antes del modelo más fuerte. Para un fallo de razonamiento confirmado en el rango 1 o 2, salta directamente al rango 3. En el rango 3 o superior, avanza un rango. "Escalar" a continuación significa esta regla. Detente cuando el trabajo inadecuado agote el rango 5. Las continuaciones productivas y los fallos ambientales corregidos no avanzan rangos. No reintentes el mismo enfoque fallido sin una corrección concreta; escala en su lugar. Esto no prohíbe continuaciones productivas.
Usa el esquema expuesto de Codex: spawn_agent con un task_name único, instrucciones completas en message, model explícito, reasoning_effort y fork_turns: "none" donde sea compatible. No uses un fork de historial completo para anulaciones. Informa controles incompatibles en lugar de cambiar la configuración global o eludirlos con una CLI anidada. Usa followup_task para continuaciones del mismo rango y un spawn nuevo para cambios de modelo/esfuerzo. Las llamadas de espera/escucha/dirección no crean asignaciones adicionales gratuitas. Interrumpe trabajadores retrasados y asegúrate de que las escrituras se detengan antes de continuar.
Registra la configuración solicitada y observable efectiva; usa unavailable cuando los valores efectivos no estén expuestos. Nunca sustituyas silenciosamente modelos o configuraciones no disponibles. Mantén rutas de evidencia en las instrucciones en lugar de copiar transcripciones. Las instrucciones de reintento nombran la corrección/hipótesis y dicen continúa el parche o reemplaza estos fragmentos.
Contabilidad y clasificación
Rastrea llamadas totales, llamadas por etapa y rango por etapa/elemento de trabajo por separado. Cada nueva asignación de trabajo, reintento o continuación cuesta una llamada; los mensajes de estado y las esperas no cuestan ninguna. Los trabajadores en paralelo y los trabajadores de prueba de referencia cuentan individualmente. Cuando sea compatible, crea una entrada de lista de tareas en tiempo de ejecución por asignación o continuación enviada; actualizarla no cuesta ninguna llamada. Un FAIL correcto de Validar es una validación exitosa, no una razón para escalar al validador. Diagnostica el fallo antes de elegir una fila.
| Hallazgo | Acción siguiente | Cuenta como |
|---|---|---|
| Trabajo inadecuado | Escala la etapa responsable con evidencia | llamada + avance/salto de rango |
| PARTIAL con enfoque sólido y progreso | Continúa en el mismo rango | llamada |
| Segundo PARTIAL en el mismo rango, o sin evidencia de progreso | Escala esa etapa | llamada + avance/salto de rango |
| Diagnóstico incorrecto | Escala Descubrir; revisa las instrucciones de implementación después | llamada + avance/salto de rango (Descubrir) |
| FAIL de Validar es incorrecto | El padre corrige con evidencia registrada, o escala Validar; no cambies Implementar | ninguna para corrección; llamada + avance/salto de rango para revalidación |
| FAIL de Validar identifica correctamente implementación inadecuada | Escala Implementar, luego nuevo Validar en su rango actual | llamada + avance/salto de rango (Implementar), llamada (Validar) |
| Validar agota el tiempo con comprobaciones completadas listadas | Continúa en su rango actual en las comprobaciones pendientes | llamada |
| Fallo ambiental o requisito previo faltante | Remedia dentro de la autorización, luego reintenta una vez; detente si no se resuelve | llamada por reintento; sin cambio de rango |
| Ambigüedad bloqueante cambia "hecho" o riesgo del nivel D | Pregunta al usuario; nombra el bloqueador | ninguna |
La corrección del padre no anula las comprobaciones: la aceptación requiere evidencia para cada criterio. Continúa la validación en el mismo agente solo si nunca implementó y el parche no ha cambiado. Después de una reparación, usa un validador nuevo. Un FAIL correcto en el rango 5 no agota al validador; clasifica la implementación.
Presupuestos: A 3 llamadas; B 4; C/D 8. Verifica antes del envío: las llamadas restantes deben cubrir todos los trabajadores propuestos más un Validar final cuando su trabajo lo requiera. Validar solo necesita su propia llamada. Una restante + Validar final está permitido; dos restantes + Implementar está permitido; dos restantes + dos Implementar no. Reduce un lote solo si todo el trabajo requerido aún cabe. Reserva implementación y validación después del descubrimiento. Vuelve a verificar después de la promoción.
La última llamada permitida puede completar la tarea con éxito. De lo contrario, detente antes de un trabajo inasequible, ante un fallo en el rango final o por bloqueadores no resueltos. Nunca omitas silenciosamente trabajo requerido ni reclames finalización con validación requerida pendiente. Las elecciones ordinarias de implementación no necesitan pregunta al usuario; regístralas.
Instantáneas y transferencias
El padre solo ejecuta el script de instantáneas Bash/Git incrustado a continuación. No se necesita ningún archivo complementario. Con umask 077, crea ${TMPDIR:-/tmp}/escalating-subagents/, luego un directorio task.XXXXXX único allí usando mktemp -d. Extrae el bloque marcado con este comando, nunca reescribiéndolo (SKILL es la ruta absoluta de este documento, TASK el directorio de la tarea):
sed -n '/^<!-- agent-snapshot:start -->$/,/^<!-- agent-snapshot:end -->$/p' SKILL | sed '1,/^```bash$/d;/^```$/,$d' > TASK/agent-snapshot.sh
Su SHA-256 (shasum -a 256 o sha256sum) debe ser ddc6cd474ae00cb7fc7613deefb4a9f5ff959f6b641abf041f1a7e26d7d8ca95; una discrepancia es un bloqueador. Usa <task>/state por separado para las instantáneas. No coloques el script dentro del directorio de estado inicialmente vacío. Ejecútalo con Bash, nunca lo conviertas en fuente.
Registra las rutas absolutas del repositorio, ayudante y estado en el registro del padre; pásalas explícitamente en cada invocación, sin depender del estado del shell entre comandos. Los trabajadores nunca ejecutan el ayudante ni reciben sus rutas de control. Inicializa con éxito antes de cualquier envío; informa errores de inicialización y detente, identificando bloqueadores de la zona de pruebas solo cuando los permisos los causaron. Las palabras en mayúsculas a continuación son marcadores de posición; cita las rutas reales:
bash HELPER init REPO STATE
bash HELPER capture STATE base
bash HELPER capture STATE pre-1
bash HELPER capture STATE post-1
bash HELPER diff STATE pre-1 post-1 names0
bash HELPER diff STATE pre-1 post-1 stat
bash HELPER diff STATE base post-1 patch
Captura base una vez, pre-N inmediatamente antes de cada envío/lote y post-N después de que todos sus trabajadores y escrituras finalicen. Almacena la salida del parche integrado en la evidencia del borrador. Las instantáneas nombradas son inmutables. El estado conserva IDs de árbol e índices/objetos temporales; la base de datos real de índices/objetos no cambia. Se incluyen archivos ignorados rastreados y archivos no rastreados no ignorados. No uses git diff HEAD como sustituto.
Los fallos del ayudante son bloqueadores. Rechaza escrituras concurrentes; no elimines un bloqueo a menos que su proceso registrado esté confirmado como detenido. Las capturas interrumpidas no publicadas no pueden reemplazar instantáneas nombradas. Mantén el estado hasta que finalicen los informes y cualquier seguimiento previsto.
Usa rutas de cambio delimitadas por NUL para comprobaciones de alcance, stat para resúmenes y el parche integrado para Validar. Las ediciones fuera de alcance son rechazadas a menos que el padre extienda explícitamente la propiedad para una dependencia legítima. Preserva el trabajo no relacionado; nunca reinicies, limpies, guardes en stash ni reviertas automáticamente.
Envía trabajadores de Implementar sin superposición juntos dentro de la capacidad disponible. Para cada lote, compara con la unión de propiedad; los informes proporcionan atribución individual, no prueba de autoría. Espera a que todo el lote termine antes de verificar el alcance o validar. Serializa archivos/infraestructura compartidos y escritores concurrentes no relacionados que contaminarían las instantáneas.
Verifica resultados de comandos, rutas de evidencia, ubicaciones citadas y relevancia del estado del archivo en las transferencias. Las nuevas ediciones invalidan las comprobaciones afectadas. El trabajo aceptado avanza; el trabajo rechazado regresa a clasificación. Rastrea comandos de larga ejecución hasta su finalización y detén escrituras pendientes antes de tomar instantáneas; el lanzamiento en segundo plano no es finalización.
Restricciones del repositorio e instrucciones
Lee AGENTS.md, instrucciones específicas, especificaciones y guías de diseño aplicables. Usa el gestor de paquetes del repositorio, bloqueo, versiones de dependencias, migraciones y políticas de documentación. Lleva las restricciones de datos de producción explícitamente a las instrucciones relevantes de los trabajadores, incluidos los requisitos de datos en vivo y solo aditivos cuando corresponda; no confíes en que los trabajadores los descubran indirectamente.
Los trabajadores nunca confirman, envían, despliegan ni realizan escrituras externas no relacionadas. El padre puede realizar acciones solicitadas explícitamente solo cuando las reglas del repositorio y del host lo permitan.
Cada instrucción incluye: tarea, nivel, solicitud original, rutas absolutas del repositorio/instrucciones/evidencia, modelo/esfuerzo, criterios textuales, propiedad, tiempos de espera de comandos, presupuesto de tiempo real, restricciones de datos de producción y "no delegar, invocar esta habilidad ni ejecutar el ayudante de instantáneas".
- Descubrir: rutas relevantes, informe anterior si se reintenta; no posee nada excepto archivos de repro/prueba explícitamente autorizados. Sin ediciones de producto ni instalaciones. Informa resultado, causa/alcance, ubicaciones, evidencia, criterios propuestos, puntos abiertos y el siguiente paso, o DONE/PARTIAL/BLOCKED y el estado de alcance al finalizar.
- Cuando el alcance sea incierto, primero confirma si el error está en el archivo o la función informados. Luego, si se reproduce, verifica el alcance real abriendo todos los archivos que podrían necesitar cambios (por ejemplo, interfaz, pruebas, configuración). No saltes directamente a conclusiones ni limites la investigación a la ubicación inicial. Informa ubicaciones completas de todos los archivos relevantes.
- Implementar: propiedad; tiempo de espera de comandos.
- Validar: propiedad del validador (ninguna); tiempo de espera de comandos; no editar.
Finalización de la tarea
Cuando se cumplan los criterios y se hayan ejecutado todas las comprobaciones, detén la escalada y declara la tarea completada. Informa un resumen: nivel y rango finales, etapas ejecutadas, resumen de cambios y hallazgos de validación. Si la tarea no se completa, informa el estado alcanzado, el trabajo restante y lo que se necesita para terminar.
No registres llamadas de herramienta ni des datos de diagnóstico sin procesar en el informe final a menos que se soliciten explícitamente. Enfócate en la información procesable para el usuario.
#!/usr/bin/env bash
set -euo pipefail
# Script de instantáneas para Subagentes escalados
# Uso: bash script.sh init|capture|diff <repo> <state_dir> [args...]
COMMAND="${1:-}"
REPO="${2:-}"
STATE="${3:-}"
if [[ -z "$COMMAND" || -z "$REPO" || -z "$STATE" ]]; then
echo "Uso: bash script.sh init|capture|diff REPO STATE [args...]" >&2
exit 1
fi
STATE_DIR="$STATE"
mkdir -p "$STATE_DIR"
LOCK_FILE="$STATE_DIR/.lock"
function acquire_lock() {
local fd
exec {fd}>"$LOCK_FILE"
flock -x "$fd" || { echo "ERROR: No se pudo adquirir el bloqueo" >&2; exit 1; }
echo "$fd"
}
function release_lock() {
local fd="$1"
flock -u "$fd" 2>/dev/null || true
exec {fd}>&-
}
case "$COMMAND" in
init)
cd "$REPO"
echo "Inicializando repositorio..."
git rev-parse --git-dir > /dev/null 2>&1 || { echo "ERROR: No es un repositorio git" >&2; exit 1; }
echo "OK"
;;
capture)
local name="${4:-}"
if [[ -z "$name" ]]; then
echo "Uso: bash script.sh capture REPO STATE nombre" >&2
exit 1
fi
local lock_fd
lock_fd=$(acquire_lock)
cd "$REPO"
local output_file="$STATE_DIR/$name.json"
if [[ -f "$output_file" ]]; then
echo "ERROR: La instantánea $name ya existe" >&2
release_lock "$lock_fd"
exit 1
fi
git ls-tree -r HEAD --name-only -z | xargs -0 -I {} sh -c 'echo "{}: $(git hash-object "{}" 2>/dev/null || echo MISSING)"'
git ls-files --ignored --exclude-standard -z | xargs -0 -I {} sh -c 'echo "IGNORED: {}"'
git ls-files --others --exclude-standard -z | xargs -0 -I {} sh -c 'echo "UNTRACKED: {}"'
echo "{\"captured\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",\"tree\":\"$(git rev-parse HEAD)\"}" > "$output_file"
echo "OK: $output_file"
release_lock "$lock_fd"
;;
diff)
local name1="${4:-}"
local name2="${5:-}"
local mode="${6:-stat}"
if [[ -z "$name1" || -z "$name2" ]]; then
echo "Uso: bash script.sh diff REPO STATE nombre1 nombre2 [stat|names0|patch]" >&2
exit 1
fi
cd "$REPO"
local file1="$STATE_DIR/$name1.json"
local file2="$STATE_DIR/$name2.json"
if [[ ! -f "$file1" || ! -f "$file2" ]]; then
echo "ERROR: Una o ambas instantáneas no existen" >&2
exit 1
fi
case "$mode" in
names0)
git diff --name-only -z HEAD 2>/dev/null | tr '\0' '\n' || true
;;
stat)
git diff --stat HEAD 2>/dev/null || true
;;
patch)
git diff HEAD 2>/dev/null || true
;;
*)
echo "ERROR: Modo no soportado: $mode" >&2
exit 1
;;
esac
;;
*)
echo "ERROR: Comando desconocido: $COMMAND" >&2
echo "Comandos: init, capture, diff" >&2
exit 1
;;
esac