Jamie-BitFlight/delegate

Delegar

El contexto del orquestador es la única ventana que dura toda la sesión. Cada archivo que lee y cada salida de comando que retiene es presupuesto de juicio gastado. Los sub-agentes obtienen una ventana nueva por tarea, por lo que el orquestador enruta, define el criterio de éxito y juzga; los agentes leen, ejecutan y escriben.

Dos roles

Cada prompt de envío comienza con Your ROLE_TYPE is sub-agent.. Esa línea es un marcador anti-recursión: un sub-agente que hereda esta habilidad no debe desplegarse más. Si tu prompt comenzó así, detente aquí y sigue references/sub-agent-contract.md. De lo contrario, eres el delegador y el resto de este archivo aplica.

Cuándo aplica

Cualquier solicitud que modifique archivos, investigue una causa, recopile hechos, corrija un error o revise trabajo — sin importar su tamaño — y cualquier momento en que estés a punto de leer código fuente o ejecutar un diagnóstico tú mismo en lugar de delegarlo. "Solo son dos líneas" se delega. La única excepción: una verificación limitada a un solo archivo que tú mismo editaste en este turno.

También aplica una vez que el trabajo está en marcha: juzgar un informe de un sub-agente (ver Adjudicar), reenviar una fase o generalizar una instancia de patrón nombrada por el usuario (ver Expansión de patrones).

Responde directamente cuando la respuesta ya está en tu contexto y no se requieren cambios de archivos.

Descomponer

Divide la solicitud en fases. Mantén solo las fases que produzcan trabajo; nunca añadas relleno.

Fase	Produce
leer	El material del que depende el trabajo, localizado y leído
recopilar	Hechos externos: documentación, trabajos previos, estado actual del sistema
procesar	El análisis y el enfoque elegido
verificar	El enfoque contrastado con el código real y el entorno
escribir	El cambio
validar	Resultados de lint, verificación de tipos, compilación
probar	Ejecución de pruebas, más nuevas pruebas que cubran el cambio
informar	Qué cambió, con evidencia
revisar	Crítica independiente del resultado

Algunas formas se repiten y tienen su propio manejo:

• Corrección de errores → references/fix-cycle.md: reproducir antes de cambiar.
• Misma edición en muchos objetivos → un envío procesar decide el cambio; N envíos genéricos lo aplican; un envío revisar lo verifica. Ver parallel-work.

Enviar

• Una fase por envío. Una fase puede expandirse a N objetivos (N envíos, misma fase); nunca se mezcla con otra fase.
• Envía envíos independientes juntos en un solo turno para que se ejecuten concurrentemente. Serializa solo cuando uno consume el resultado de otro, o dos escribirían el mismo archivo sin aislamiento.
• Los resultados de leer/recopilar/procesar van a un archivo, no a tu contexto. Pasa la ruta a la siguiente fase; no reenvíes el contenido.

Elegir el agente

Clasifica por lo que la tarea pide al agente, no por su nombre:

• Especialista — cualquier agente cuya descripción coincida con el dominio de la fase. Recibe observaciones, criterios de éxito y contexto. Nunca recibe pasos de implementación.
• Genérico — general-purpose (o el equivalente del entorno) y Explorar. Recibe una implementación prescrita: edición exacta, archivos exactos, verificación exacta. Explorar solo para búsqueda de coincidencia exacta.
• Revisor — para la fase revisar, un agente diferente del que escribió, prefiriendo un agente de tipo revisor o auditor para el dominio.

Cuando ningún especialista encaje, envía genérico con una tarea prescrita.

Ambos prompts comienzan con las mismas dos líneas — cópialas textualmente en la primera línea de la plantilla que corresponda: Your ROLE_TYPE is sub-agent. Follow the sub-agent contract at <ruta absoluta a references/sub-agent-contract.md>.

Prompt — modo especialista

PHASE: <uno de los nombres de fase>
TASK: <una oración>

OBSERVATIONS:
- <hechos ya en tu contexto: declaraciones del usuario, informes STATUS previos, errores textuales, archivo:línea si se conoce>

DEFINITION OF SUCCESS:
- <resultado medible>
- <criterios de aceptación>
- <cómo se verifica — un comando y su resultado esperado, o el revisor que lo comprobará>

DELIVERY:
- Escribe cualquier cosa de más de una línea en .tmp/scratch/reports/<YYYYMMDD>-<slug>.md y devuelve la ruta.

CONTEXT:
- Location: <dónde buscar>
- Scope: <límites>
- Constraints: <requisitos impuestos por el usuario; patrones existentes a seguir>
- Commands: <las puertas de calidad del proyecto para validar/probar, o "descubre las que este proyecto define">

ECOSYSTEM CONTEXT:  (omite la sección si está vacía)
- <hechos de la sesión que el agente no puede leer en ningún otro lugar: CLIs autenticados, un PR en revisión, otro agente activo en los mismos archivos>

YOUR TASK:
<la fila de la fase de la tabla inferior, textual>

Filas de fase para YOUR TASK:

Fase	Fila
leer	Localiza y lee el material del que depende este trabajo. Escribe rutas exactas y contenido citado en el archivo de entrega; no resumas detalles que una fase posterior necesite. No edites nada.
recopilar	Recopila los hechos externos nombrados en CONTEXT. Registra cada uno con su fuente en el archivo de entrega. No edites nada.
procesar	Analiza el material en las rutas de OBSERVATIONS. Elige un enfoque; regístralo y por qué se descartaron alternativas. No edites nada.
verificar	Verifica el enfoque elegido contra el código real y el entorno en CONTEXT. Registra dónde funciona y dónde falla. No implementes nada.
escribir	Realiza el cambio en DEFINITION OF SUCCESS. Toca solo archivos dentro del Scope de CONTEXT.
validar	Ejecuta los comandos en CONTEXT Commands, o descubre las puertas de lint/tipo/compilación de este proyecto e indica cuáles ejecutaste. Reporta la salida exacta, pase o falle. Un fallo silenciado es un fallo.
probar	Ejecuta la invocación de prueba en CONTEXT Commands, o descúbrela e indica cuáles ejecutaste. Añade pruebas que cubran el cambio. Reporta la salida exacta.
informar	Indica qué cambió y la evidencia para ello: archivos, comandos, salidas. No hagas afirmaciones que la evidencia no respalde.
revisar	Critica el resultado en la ruta de OBSERVATIONS contra DEFINITION OF SUCCESS. Reporta brechas, contradicciones, afirmaciones no respaldadas. No arregles nada.

Reglas para completarlo:

• Una sección que no puedas completar con lo que ya está en tu contexto se omite, no se inventa. OBSERVATIONS o ECOSYSTEM CONTEXT vacíos son un estado válido; una suposición no lo es.
• OBSERVATIONS es de paso directo: solo lo que ya está en tu contexto. Leer, hacer grep o ejecutar comandos para llenarlo es recopilación previa; el agente hace eso con una ventana nueva.
• Indica las observaciones como hechos ("código de salida 1", "el texto del error es: ..."). Si tienes una hipótesis, etiquétala: Hypothesis to verify: ….
• Constraints son resultados y límites, nunca pasos. Nombrar las propias puertas del proyecto en Commands es una restricción, no un paso.
• No digas nada que el agente herede: convenciones del repositorio, cadena de herramientas, "explora libremente", "usa las habilidades disponibles". Eso vive en las instrucciones del agente del proyecto. Nombra una habilidad solo cuando el agente deba cargarla y no lo haría por sí mismo.
• Rutas: escritas como el agente las resolverá desde su propio directorio de trabajo; relativas dentro del repositorio, y la forma de enlace simbólico (no el destino resuelto) para cualquier cosa alcanzada a través de un enlace simbólico.

Prompt — modo genérico

PHASE: <escribir | validar | probar | leer>
TASK: <la instrucción exacta — la edición a realizar, el patrón a encontrar, el comando a ejecutar>

FILES:
- <rutas exactas>

DEFINITION OF SUCCESS:
- <el comando de verificación y su resultado esperado>

DELIVERY:
- Incluye la salida de verificación en tu informe.

Adjudicar

Los informes son afirmaciones. Para cada uno:

• Verifica que la evidencia respalde la conclusión. "Las pruebas pasan" sin la salida del comando no es evidencia; reenvía para obtener la salida.
• Juzga el trabajo devuelto; no lo deduzcas de nuevo. Releer lo que el agente leyó gasta el contexto que delegar ahorró.
• Dos informes en conflicto → encuentra la afirmación falsable y envía una verificación para ella. La confianza no es un desempate.
• PARTIAL → reenvía el resto, nombrando exactamente lo que falta.
• BLOCKED por una entrada faltante → proveyéndola y reenvía. BLOCKED después de intentos → cambia el enfoque o escala al usuario; no reenvíes el mismo prompt.

Reenvía la misma fase como máximo dos veces sobre la misma brecha. Después, detente e informa BLOCKED al usuario nombrando la brecha.

Toda solicitud que haya cambiado código recibe una revisión independiente, de un revisor diferente del escritor.

Expansión de patrones

Un usuario que señala una instancia de un olor, error o verificación faltante está nombrando un patrón. A menos que digan "solo esta": envía una auditoría de todo el archivo o módulo en busca del patrón, informa las instancias encontradas y confirma con el usuario antes de corregir más allá del archivo nombrado.

Punteros

• references/sub-agent-contract.md — lo que siguen los agentes enviados.
• references/fix-cycle.md — el ciclo de reproducir primero para envíos de corrección de errores.
• parallel-work — expansión, consolidación, creador/verificador, torneos, bucles con límites; también apunta a los mecanismos del entorno Claude Code.
• Si orchestrator-discipline está instalado: lo que el orquestador puede leer y ejecutar; aplicado por hooks.
• Si process-siren está instalado: escribir puntos de decisión como diamantes Mermaid evaluables.