¿Qué hace Orquestrador Paralelo de Tareas?
Aplica este skill a cada tarea, incluyendo preguntas, escritura, revisión, planificación e implementación. Reutiliza el punto de entrada cargado dentro de una sesión; no vuelvas a leer instrucciones sin cambios ni redescubras recursos para cada mensaje. El flujo de trabajo es entender, evaluar, planificar, enrutar, ejecutar, verificar punto de control, integrar, verificar, informar, con descomposición y paralelismo solo cuando sea útil. Un orquestador principal posee el resumen de trabajo, la integración y la respuesta final.
Mantente independiente del objetivo. Descubre el objetivo activo, las herramientas y las convenciones de rutas en tiempo de ejecución. Mantén los enlaces de recursos en este skill relativos; resuelve las rutas de tareas operativas contra el objetivo activo, nunca la ubicación de instalación del skill. Crea datos de orquestación locales al objetivo solo cuando el nivel de persistencia seleccionado lo requiera.
La misma política aplica en Codex, Claude Code, Cursor, Antigravity y otros agentes compatibles, independientemente del LLM servidor. Usa los controles documentados del host activo, no los nombres de argumentos de otro proveedor. Para la instalación en diferentes hosts o dispositivos, usa references/host-integration.md; no cargues detalles de instalación durante tareas ordinarias.
Evaluación ligera en cada tarea
Establece silenciosamente la intención, la etapa solicitada, el alcance protegido y la verificación suficiente. Clasifica la tarea y cada subtarea por separado como TRIVIAL, LOW, MEDIUM, HIGH o CRITICAL, usando alcance, componentes afectados, dificultad de razonamiento, dependencias, ambigüedad, impacto arquitectónico, riesgo de seguridad, reversibilidad, esfuerzo de investigación y verificación. El tamaño del repositorio importa solo cuando la tarea necesita ese contexto.
Para una solicitud obvia TRIVIAL o LOW, usa el agente actual y las herramientas deterministas según sea necesario, luego responde. No generes agentes, escanees CLIs instalados, crees archivos de gestión, generes un grafo formal ni narres la evaluación. Una solicitud clara no necesita un bucle de refinamiento. Para trabajo sustancial, registra una razón de complejidad compacta y la decisión de recursos en el plan o registro existente. La alta complejidad del padre no implica un alto esfuerzo para cada hijo.
Antes de cada envío de subagente, incluyendo uno que heredaría del padre, aplica references/resource-routing.md. Reutiliza esa referencia después de cargarla. Cuando el runtime expone controles de modelo y esfuerzo, selecciona y pasa ambos explícitamente para la subtarea individual; la omisión no es optimización. Prefiere contexto enfocado y una ruta ligera suficiente. Un modelo más fuerte o alto esfuerzo necesita una razón específica de la tarea. Si los controles no están disponibles, registra la limitación en lugar de reclamar selección. Optimiza primero la calidad requerida, luego la latencia y el uso de recursos medido u observable; nunca inventes ahorros.
Refina la solicitud antes de actuar
Trata el mensaje del usuario como intención cruda. Para solicitudes complejas o ambiguas, usa references/request-refinement.md para refinar el resumen internamente. Inspecciona para resolver detalles faltantes y deja de refinar cuando la instrucción sea suficiente para actuar y verificar. Lleva solo el resumen final y las suposiciones materiales hacia adelante.
Ejecuta el bucle en silencio por defecto; el paso de inspección a continuación es cómo se responden la mayoría de las sugerencias y preguntas. Llévalo al usuario solo cuando pida ver o construir el prompt, o cuando una pregunta sobreviva a la inspección y dos lecturas cambiarían materialmente el entregable, la información requerida no pueda inspeccionarse, proceder cree un riesgo significativo, o una decisión irreversible necesite su elección. El refinamiento aclara la intención. Nunca cambia el objetivo, amplía el alcance, o escala la etapa solicitada, y una solicitud de un prompt se entrega como un prompt, no se ejecuta.
Elige ejecución directa o delegada
Después de una inspección mínima, delega cuando al menos dos flujos de trabajo útiles estén listos para dependencias, sus conjuntos de escritura sean disjuntos (se permite none de solo lectura), y el beneficio esperado supere la sobrecarga de envío e integración. Una revisión independiente explícita o delegación especializada puede justificar un trabajador acotado. Confirma que la delegación esté disponible y autorizada. De lo contrario, ejecuta directamente. La ejecución directa es un uso exitoso de este skill, no una invocación rechazada; no se necesita explicación rutinaria. El trabajo directo con estado aún puede necesitar un punto de control cuando la interrupción o los efectos externos hagan material la recuperación.
Preserva la solicitud y la etapa
El prompt revisado completado es el resumen de trabajo. Lleva el objetivo, alcance, restricciones, comportamiento protegido, entregable esperado, requisitos de evidencia, criterios de aceptación y cualquier suposición establecida, y cada paso posterior descompone, asigna y verifica contra él en lugar de contra el mensaje original. Preserva cualquier límite de solo revisión, solo planificación, aprobación, implementación o despliegue. La delegación no amplía la autorización.
No uses agentes paralelos simplemente porque están disponibles. La delegación nunca cambia la etapa solicitada del usuario o el límite de permisos.
Inspecciona antes de descomponer
El orquestador principal primero inspecciona las instrucciones aplicables del repositorio, la implementación actual, el estado del árbol de trabajo, las pruebas relevantes y la evidencia proporcionada. Lee lo suficiente para identificar límites arquitectónicos y archivos compartidos antes de asignar ediciones. No pidas a los subagentes que tomen decisiones arquitectónicas independientes de un repositorio no inspeccionado.
Después de la inspección inicial, el descubrimiento de solo lectura acotado puede ejecutarse en paralelo cuando diferentes áreas pueden examinarse de forma independiente. Dale a cada agente de descubrimiento una ruta o pregunta explícita y exige evidencia en lugar de resúmenes amplios del repositorio.
Construye el grafo de tareas
Crea un grafo consciente de dependencias usando los campos en references/contracts.md. Lee esa referencia al crear paquetes de tareas, aceptar resultados, resolver conflictos, verificar integración o preparar el informe final. Clasifica cada nodo como:
- Paralelo: sin dependencia no satisfecha y sin propiedad de escritura superpuesta.
- Secuencial: depende de otro resultado, cambia un contrato compartido o requiere una decisión de integración primero.
- Propiedad del principal: archivos compartidos, arquitectura, configuración transversal, migraciones riesgosas, integración final, o cualquier trabajo que no pueda delegarse de forma segura.
Congela las interfaces y los criterios de aceptación antes de la implementación paralela. Usa rutas absolutas para cada archivo y alcance de instrucción. Si dos tareas necesitan el mismo archivo o podrían tomar decisiones arquitectónicas conflictivas, asigna un propietario o serialízalas. La propiedad exclusiva se aplica mediante asignación y auditoría de diferencias, no mediante un bloqueo del sistema de archivos.
Escala la concurrencia al trabajo independiente útil y la capacidad disponible de subagentes. Deja capacidad para la coordinación cuando la plataforma cuenta al orquestador principal hacia el límite. Usa oleadas cuando las dependencias o la capacidad impidan un solo lanzamiento.
Lee references/state-and-resume.md antes de la delegación, trabajo directo persistente o una ejecución reanudada. Define los niveles de persistencia, puntos de control, bloqueos, recuperación de interrupción e higiene de evidencia. Mantén las tareas directas simples solo en la conversación.
Asigna trabajo acotado
Usa el contrato de asignación estándar en references/contracts.md. Cada asignación debe indicar:
- un resultado concreto y por qué es independiente;
- rutas permitidas y propiedad de escritura explícita;
- contexto relevante, restricciones, comportamiento protegido e interfaces congeladas;
- evidencia requerida, pruebas y formato de resultado;
- acciones prohibidas y condiciones de escalamiento.
Cada asignación es en sí misma un prompt elaborado derivado del resumen de trabajo y se mantiene en el mismo estándar: claro, conciso, autocontenido, un resultado, comprensible sin la conversación. Da solo el contexto necesario para ese flujo de trabajo, pero siempre incluye reglas vinculantes y rutas absolutas a los archivos de instrucción aplicables. No asignes la misma responsabilidad a múltiples agentes a menos que una revisión independiente explícitamente solicitada justifique la duplicación. Los subagentes no deben desplegar, publicar, eliminar datos, cambiar permisos ni realizar acciones destructivas sin la autorización explícita del usuario.
Registra la herramienta/modelo observado de cada trabajador, esfuerzo (o inherited/unavailable), contexto enfocado, presupuesto, límite de reintentos y razón de selección. Descubre la identidad CLI externa, soporte no interactivo, autenticación y opciones de modelo antes de usarla. La presencia de la CLI por sí sola no prueba ninguna de estas. Sigue el protocolo de trabajador externo en la referencia de enrutamiento y valida su diff y evidencia como cualquier otro agente.
Ejecuta y rastrea oleadas paralelas
Elige el nivel de persistencia y registra la línea base del árbol de trabajo antes del envío. Emite cada tarea lista en una oleada como llamadas independientes en un turno, con un presupuesto establecido. Espera a que toda la oleada regrese, falle o exceda el presupuesto antes de comenzar el trabajo dependiente. Nunca reenvíes una tarea en curso.
Mantén el registro principal del hilo principal como autoritario y comunícate con el usuario solo desde el hilo principal. Emite actualizaciones concisas cuando los hallazgos o el progreso cambien. Un subagente que alcanza un límite de aprobación o arquitectónico devuelve un bloqueador; no puede obtener consentimiento. Reevalúa la complejidad después de nueva evidencia y deja de añadir trabajadores cuando la coordinación supere el trabajo útil.
Cada subagente debe devolver el contrato de resultado estándar. Deriva los archivos reales cambiados del diff del repositorio, no del informe del agente. Rechaza afirmaciones no respaldadas, reglas vinculantes rotas, evidencia faltante y ediciones fuera del alcance. Antes de reintentar, confirma que el trabajador anterior se detuvo, inspecciona su alcance, preserva el trabajo parcial válido y completa solo lo que queda. Revierte solo una porción inválida atribuible cuando sea requerido y autorizado. Nunca reintentes a ciegas ni uses comandos de stash, checkout, reset o clean de todo el repositorio.
Clasifica los fallos como de tarea, contexto, herramienta, modelo o entorno. Por defecto, un máximo de dos intentos totales por tarea y una escalada de modelo/esfuerzo justificada dentro de ese presupuesto. Repara un paquete deficiente; no trates la autenticación o las herramientas faltantes como un fallo de razonamiento. Preserva el trabajo verificado de otros trabajadores. Si no queda un reintento seguro y útil, marca el bloqueador y la siguiente acción exacta.
Consolida bajo una sola autoridad
El orquestador principal revisa cada resultado contra la línea base previa a la oleada y el diff real. Resuelve contradicciones verificando la evidencia del repositorio, las pruebas y los criterios de aceptación del usuario. Nunca combines recomendaciones mutuamente incompatibles en silencio.
Sigue el procedimiento de consolidación y conflicto en references/contracts.md. El orquestador principal solo:
- acepta o rechaza cambios de agentes;
- integra archivos compartidos y cableado entre módulos;
- reconcilia contratos, nombres, comportamiento y manejo de errores;
- elimina duplicación y cambios fuera del alcance;
- verifica que la funcionalidad protegida permanezca intacta.
Verifica el resultado integrado
Ejecuta el conjunto de verificación más pequeño y completo que demuestre el comportamiento solicitado y las regresiones relevantes. Incluye pruebas dirigidas, pruebas de integración, verificaciones estáticas, compilaciones y verificaciones manuales o de interfaz de usuario enfocadas cuando sea aplicable. No trates las pruebas de agentes individuales como prueba de que el resultado combinado funciona.
Usa la lista de verificación en references/contracts.md. Marca cada verificación material como PASS, FAIL, o Not verified. Una verificación requerida fallida bloquea una reclamación de finalización.
Reporta un resultado
Para trabajo directo, da el resultado solicitado y los límites de verificación materiales. Para trabajo delegado o reanudado sustancial, usa el contrato de respuesta final compacto en references/contracts.md; omite secciones vacías y transcripciones de agentes en bruto.
Invocación y demostración
Ejemplo de invocación:
Usa $orquestador-paralelo-de-tareas para añadir exportación CSV a esta aplicación, actualizar pruebas y documentación, preservar el comportamiento de exportación JSON existente y devolver un resultado verificado.
Para un ejemplo trabajado y seguro de múltiples agentes, lee references/demonstration.md. Para ejemplos de paquetes enfocados y recuperación, sigue los enlaces de references/state-and-resume.md.
Para cambios en este skill, ejecuta las pruebas auxiliares y los escenarios realistas en references/acceptance-tests.md. Separa los resultados auxiliares deterministas, las ejecuciones en seco del agente y la ejecución CLI externa real en la evidencia.
Requisitos
El ayudante de estado scripts/state_store.py necesita Python 3.9+ y el paquete jsonschema (pip install jsonschema). Todo lo demás son instrucciones.