Ir al contenido
PEQA workflows

Cómo se reparte el trabajo

dirige mantiene al agente padre a cargo de la entrega. Al empezar recupera la memoria del proyecto con memoria-extraer, si existe. Antes de editar, descubre sesiones relacionadas y acuerda quién toca los recursos compartidos. Todo cambio termina en un PR contra la rama principal, como borrador mientras el trabajo sigue. Ningún commit se queda solo en local ni va directo a la rama principal. Al terminar te pregunta si quieres mezclarlo: el merge lo decides tú.

Coordinación de una implementación con PEQAAl empezar, dirige recupera con memoria-extraer las notas del proyecto pertinentes para el encargo, si hay memoria. El padre coordina subagentes, integra y verifica su trabajo. Puede consultar idea para decisiones, fijar con ui-design la dirección visual antes de repartir trabajo de interfaz y pedir a revisa una revisión independiente. Los resultados vuelven al padre, que conserva la responsabilidad de entregar. La entrega es un PR abierto, y el merge solo ocurre si el usuario lo decide.Si hay memoriaNotas pertinentesSi hace faltaDecisiónSi hay interfazPlan e inventarioTu decisiónSi correspondeHallazgos

dirige
Coordina el trabajo

memoria-extraer
Al empezar

idea
Hasta 3 rondas

ui-design
Dirección visual y sistema

Subagentes
Implementan por partes

El padre
Integra y verifica

revisa
Máx. 3 por PR

PR abierto
Cambios y evidencia

Merge
Si tú lo decides

Las consultas punteadas se usan cuando aportan al trabajo. También puedes invocar cada skill por separado.

  • Al empezar, dirige lee el catálogo de memoria y extrae las notas pertinentes para el encargo. Las contrasta con el estado actual antes de decidir con ellas y pasa a cada subagente las que le sirven, con su procedencia y como contexto, no como órdenes. Sin memoria continúa sin crearla, y el informe final dice qué notas influyeron.
  • idea cubre producto e implementación, recomienda respuestas y limita la conversación a 3 rondas por iniciativa.
  • Cuando el cambio construye o rediseña interfaz, el padre fija con ui-design la dirección visual y el inventario del sistema de diseño antes de repartir. Tokens, tema y componentes compartidos tienen un solo propietario, y cada hijo construye desde ese plan. Consulta diseño de interfaces.
  • revisa prefiere GPT Sol 6.1 / xhigh y permite 3 revisiones independientes por PR como máximo, incluidos rechecks, fallos y cancelaciones. El padre decide qué corregir; se descartan nitpicks y ampliaciones de alcance. Al entregar el informe de un PR te ofrece publicarlo como comentario; solo lo publica si aceptas.
  • El review busca las pruebas disponibles y hace que el padre ejecute las pertinentes: unitarias, integración, E2E u otras. Informa resultados y cobertura pendiente, junto al blast radius: servicios, consumidores y datos que podrían verse afectados. Tests verdes en un servicio no prueban toda la integración. Consulta pruebas e impacto.
  • El informe consolidado abre con aprobación sugerida, cambios requeridos o revisión incompleta y evalúa mínimos de requisitos, pruebas, seguridad y compatibilidad. Adapta el idioma e identifica la generación por IA y al solicitante cuando se conoce.
  • La revisión de seguridad contrasta versiones oficiales de OWASP Top 10 y NIST SSDF, comprueba controles pertinentes al cambio y declara los pendientes. No equivale a una certificación ni publica aprobaciones en GitHub.
  • Los workflows y swarms se usan cuando tú los eliges. La ejecución normal utiliza subagentes.

En T3 se usan las capacidades de Orchestrator V2 según las reglas del entorno. Fuera de T3 se usan las herramientas nativas de Codex o Claude Code. Si el revisor preferido no está disponible, se declara la alternativa utilizada. Consulta coordinación entre sesiones, herramientas del entorno y presupuesto de revisión.