AGENTIC QA · WORKFLOW SKILL
Una sesión conduce una flota de testers, uno por ticket, y el owner mira todo el sprint desde un solo punto fijo: el Sprint Board.
El mapa completo · índice del deck
Sesión del conductor en .session/sprint-conductor/sprint-<N>/: kickoff, pases y refinamientos. Los briefs y el launch.txt siguen en la sesión de sprint-testing.
Roles · y dónde vive cada regla
| Quién | Hace | Nunca hace |
|---|---|---|
| Owner | decide desde el board o el chat; su respuesta por chat vale igual | leer terminales |
| Conductor | arranca, vigila, lanza, responde, cierra; dueño del estado compartido y del registro del sprint | probar o investigar un ticket; escribirle a un developer sin orden del owner |
| Worker | un ticket de punta a punta con /sprint-testing, sin checkpoints | loguearse, sincronizar el tracker entero, escribir el registro del sprint |
El QUÉ
fleet-conductor.md: briefs, launch.txt, rondas, claims, dashboard.
El board
sprint-board.md: comandos por etapa, los cuatro canales, el sentinel.
El CÓMO
orca-orchestration: Run, lanzamiento nativo, mailbox, cierre.
La puerta · antes de cualquier otra cosa
Estado C · listo
Binario presente y runtime alcanzable: sigue con Phase 0.
Estado B · binario sin runtime
Abre la app una vez y vuelve a probar una vez; si sigue sin responder, es el estado A.
Estado A · sin binario
Una sola línea: el conductor corre sobre Orca, no hay runtime en esta máquina, y el sprint se corre con /sprint-testing sprint-wide con N ejecutores, que escribe las líneas para pegar. No escribe nada más.
Toda otra skill de flujo sigue sin nombrar al orquestador cuando falta. Esta lo nombra porque el owner la invocó para correr sobre Orca. La flota sin Orca sigue existiendo, y es de sprint-testing.
Boot · un solo pase
| # | Hace | Detalle en |
|---|---|---|
| 1 | carga esta skill, sprint-testing con sus dos referencias de flota, orca-orchestration y sus stubs | orca-orchestration |
| 2 | resuelve el sprint y el board; sync --discover; levanta el server si no responde | sprint-board.md §1 |
| 3 | el pre-flight del conductor | boot-and-resume.md §2 |
| 4 | enlaza o crea el Run y prueba la dirección de respuesta una vez | boot-and-resume.md §3 |
| 5 | arma el sentinel en segundo plano, con su baseline | sprint-board.md §7 |
| 6 | lee el mailbox, el inbox y el replay de listen --since; primer watch pass | watch-pass.md |
| 7 | una pantalla: conteos, quién espera a quién, decisiones numeradas | SKILL.md |
Al owner solo le pregunta dos cosas: el sprint, si el board y el tracker no coinciden, y el tope de workers, si hay más tickets que el tope y no dio uno.
Boot · antes de CADA lanzamiento
Tokens y estados del browser
Los genera el conductor, renovando solo los vencidos. La credencial se prueba primero con el login por API: tres intentos fallidos y se pregunta.
Repos hermanos: el fetch es un gate
Dos comparaciones, remoto contra remoto y árbol local contra lo desplegado. Un fetch que falla deja los conteos en 0 sobre refs viejas: se escala, nunca se cuenta.
Schema de la API
Se sincroniza desde un árbol al día, o el salto queda escrito en cada brief con la fecha real del último sync.
Build desplegado y fixtures
El build por repo queda como baseline en kickoff.md. Los datos que un caso necesita y no existen se preguntan ahora, no cuando un worker los descubre.
Loop · un pase por cada wake del sentinel
Idempotente
Cada decisión queda con board arrival launched|held|skipped. Un pase perdido no cuesta nada: el ticket aparece en el siguiente.
El deploy check nunca se saltea
El commit del cambio dentro del build desplegado, y los archivos del cambio leídos: una parte que el pipeline no despliega no queda probada por un deploy verde.
Watch pass · cada pase compara el build
Mismo build
Nada que hacer.
Cambió, sin workers
Se actualiza el baseline en kickoff.md.
Cambió, con workers vivos
Solo fetch, nunca fast-forward de un repo hermano. Un aviso a cada worker: repo, build viejo y nuevo, y si se movieron los archivos de su propio cambio.
El entorno se redesplegó con cuatro workers corriendo y solo uno lo notó, por su cuenta.
Cierre · el reporte es una afirmación, no la prueba
Por qué no alcanza con el reporte
En la flota de origen un subagente reportó el estado aprobado "directo del tracker"; diez minutos después el tracker seguía en el estado anterior. Un "verificado" ajeno nunca es la prueba.
--resume · un reinicio mata todos los procesos
| # | Paso |
|---|---|
| 1 | encontrar los workers por título, nunca por un handle viejo; actualizar roster y board; re-enlazar los dispatch |
| 2 | levantar el server del board |
| 3 | re-armar el sentinel con el MISMO baseline |
| 4 | replay de lo que hizo el owner con listen --since, más el inbox |
| 5 | leer el mailbox |
| 6 | un mensaje por worker vivo: sesión de browser con nombre, desde el último paso VERIFICADO |
| 7 | ningún lanzamiento nuevo hasta que todos respondan |
Límites · cada uno pagado en una flota real
No investiga
Leer el controller y consultar la base para un caso es trabajo del worker, que tiene más contexto y escribe el ATR.
No escribe a developers
Redacta en el board y el owner envía, salvo orden explícita para ese mensaje.
No vigila a mano
Nada de monitores caseros ni de leer el mailbox en loop: el sentinel y el runtime avisan.
Tampoco commitea ni imprime credenciales, y le reporta al owner en conteos y tablas que nombran a quién preguntar.
Para llevarte
Boot
Siete pasos, el pre-flight del conductor y una pantalla de estado.
Watch pass
Un pase por wake, el deploy check siempre, cada decisión en el board.
Cierre y retoma
Relectura propia, un subagente que verifica, y un retome que no repite escrituras.
Pruébalo: /sprint-conductor · ← → navegar · S presentador · O overview