AGENTIC QA · WORKFLOW SKILL · SHIFT-LEFT

/shift-left-testing

QA pre-sprint sobre un lote de Stories del backlog: refina los Acceptance Criteria, saca a la luz gaps y ambigüedades, y deja redactado el ATP real de cada Story en madurez outline. Los defectos se previenen en los requisitos, antes de que alguien escriba una línea de la feature.

Shift-Left (históricamente Stage 0) · Pre-sprint Batch de 1-12 Stories Sin ejecución: la feature no existe Jira es canónico
Bienvenidos. Este deck recorre el workflow real del skill /shift-left-testing paso a paso: qué entra, qué hace la IA, qué gates esperan tu aprobación y qué artefactos salen. Regla de oro: corregir un defecto en los requisitos cuesta 1; en desarrollo, 10; en producción, 100.

el mapa completo: índice mental del deck

Un pipeline, tres fases + gates humanos

!Preflight Gate
Readiness de tooling + contexto: los mapas tienen que estar generados, no solo presentes. Args-as-answers · probe, don't assume. Un solo checklist de gaps; RED bloqueante → STOP.
RED → arregla .env + reiniciaplaceholder → project-context
0Session Init
Resume check · modalidad TMS A/B · carga /acli · verifica contexto · resuelve candidatos · crea .session/<batch-id>/
falta contexto → STOP + handoff
1Selection
Sync-read por candidato → filtro de tipo → frescura de label → veto → risk score → tabla ranqueada · tras el OK, subtask [QA] Shift-Left Review por Story
GATE · OK del usuariono-Story → rechazo en voz alta
2Refinement ×N
1 subagente por Story, SECUENCIAL · playbook en alcance outline → buffer shift-left-refinement.md + resumen por Story
GATE · OK por Storyfleet opcional: 1 worker/Story
3Handoff ×N
Mutaciones Jira por Story · labels · qa_assignee · transición Backlog → Shift-Left QA → Estimation y STOP · light stage verifier
campo ausente → comment fallbacksubtask → Close vía complete
✓Batch report
Agrega preguntas PO/Dev (dedupe) → batch-report.md → comment en el epic padre si comparten uno · archiva la sesión · session footer en el chat
→ /sprint-testing · cortocircuito

GATE espera aprobación humana  ·  caja punteada fallback / camino adyacente  ·  → handoff a otra skill

El contrato agéntico de Shift-Left

El agente reescribe los ACs como Given/When/Then con datos concretos, saca a la luz gaps y ambigüedades, redacta el ATP pre-sprint en el campo de la Story y aplica el Test-Design Checklist. La persona firma el lote de Stories candidatas y el resumen por Story, y nunca deja pasar una Story a Estimation sin eso. Evidencia que sobrevive: los ACs reescritos, los gaps como preguntas abiertas a PO/Dev, la label fechada y la subtask de revisión. Autonomía CSA 2 y sin verificador separado: el PO o el dev que refina la Story es el revisor natural.

Memoriza esta columna: Preflight → Init → Selection → Refinement → Handoff → Batch report. Cada fila es una sección del deck; al final vienen el verificador de cierre, el session footer y el fleet opcional. A la derecha viven los caminos adyacentes: gates de aprobación, fallbacks y handoffs hacia otras skills.

antes de la Phase 0: readiness gate

Preflight: probar, no asumir

Ley 1 · Args-as-answers

Lo que el usuario ya dijo (los IDs de Story, la modalidad, "groom the backlog") cuenta como respuesta dada. Solo se preguntan los gaps reales, todos juntos, en UN checklist.

Ley 2 · Probe, don't assume

Cada capacidad se verifica con un probe real. Un RED bloqueante detiene la sesión: la skill nombra la env var exacta, apunta a .env y pide reiniciar la sesión del agente.

CapacidadNecesidadProbe / por qué
/acli (issue tracker)REQUIREDbun run jira:check: todo el output del refinamiento aterriza en Jira
Modalidad TMS resueltaREQUIREDA: Xray · B: Jira-native. Se persiste para /sprint-testing; el ATP pre-sprint vive en el campo en AMBAS
/xray-cli + creds XRAY_*N/ANo se usa pre-sprint: el ATP es field-first y el Test Plan item lo crea /sprint-testing Planning desde el campo
Mapas de negocio + MTPREQUIREDbusiness-data-context, business-api-context y business-e2e-context existen Y están generados: bun run context:map <slug> --list lista secciones, sin aviso de placeholder. Más master-test-plan.md. Falta la skill → bun sync · placeholder → el modo de project-context · falta el MTP → bun run context:hydrate (y si el Epic no tiene plan, modo test-plan)
Lista de candidatosREQUIREDIDs explícitos o JQL de backlog, tamaño confirmado con el usuario

Gate ligero por diseño

Shift-left nunca ejecuta contra un sistema vivo: env de la app, credenciales de test-user, DBHub, OpenAPI, Playwright y resend son N/A aquí. La viabilidad se establece LEYENDO código, APIs y schema, jamás corriendo la app.

El preflight corre antes que todo, incluso antes del resume check. Sus dos leyes evitan los dos fallos clásicos: interrogar al usuario por cosas que ya dijo, y asumir que una CLI está autenticada sin probarla. Y un mapa placeholder pasa un chequeo de "el archivo existe" sin traer nada: por eso el probe es --list.

phase 0: session resume check + init

Phase 0 · Arrancar o retomar la sesión

  • 0.0 Resume check. Existe progress.md del batch? → ofrecer resume / restart / abort. Restart archiva lo anterior como -aborted.
  • 0.1 Modalidad TMS. El mismo probe automático de test-documentation §Phase 0 (A: Xray · B: Jira-native); solo pregunta si fallan los chequeos. Se persiste en plan.md §Inputs.
  • 0.2 Tool skills. /acli siempre (escrituras + búsqueda trivial). Lecturas de detalle → bun run jira:sync-issues, nunca acli view.
  • 0.3 Contexto generado. bun run context:map <slug> --list por cada mapa de negocio + el master test plan. Que el archivo exista no alcanza: un placeholder pasa ese chequeo vacío. Aviso de placeholder o plan ausente → STOP → /project-discovery o el modo de project-context.
  • 0.4 Candidatos. IDs explícitos (UPEX-100,101,102) o JQL de backlog. Sweet spot 1-12; >12 se divide en sesiones.
  • 0.5 Carpeta de sesión + plan.md (Goal · Inputs · fases · riesgos) + primer entry en progress.md.
estado de sesión: dónde vive cada cosa
.session/shift-left-testing/2026-07-06-payments/
├─ plan.md          # canónico: modalidad + candidatos + fases
├─ progress.md      # append-only, 1 entry por fase → resume
├─ candidates.md    # output de Phase 1
└─ batch-report.md  # output de Phase 3

# buffer [LOCAL] por Story (gitignored, desechable
# una vez que Phase 3 lo publica en el campo ATP):
.context/PBI/epics/EPIC-<KEY>-<slug>/stories/
  STORY-<KEY>-<slug>/shift-left-refinement.md

# al cerrar: mv → .session/.archive/<fecha>-...-<batch-id>/
La sesión es resumible por diseño: plan.md es el registro canónico de decisiones y progress.md permite retomar a mitad de lote sin repetir Stories ya refinadas. El descriptor kebab-case permite dos sesiones el mismo día.

phase 1: selection · el embudo de triage

Selection: leer bien, filtrar en voz alta

lectura de detalle: regla reads-vs-writes
$ bun run jira:sync-issues get UPEX-100 --include-comments   # 1 Story: ACs + custom fields + comments
$ bun run jira:sync-issues jql "project = UPEX AND issueType = Story AND status in (Backlog, ...)"
# NUNCA `acli view` para custom fields: devuelve null. `acli search` solo para la lista trivial.
1

Filtro de tipo

Solo Stories. Bug / Spike / Sub-task / Tech-debt → rechazo CON motivo de una línea, nunca en silencio.

2

Frescura de label

Ya shift-left-reviewed y una label fechada de <30 días? Se muestra aparte: el usuario decide skip o refresh.

3

Tabla de veto

Money / auth / data-integrity / integración / state machine → FORZAR FULL. CSS puro / copy / docs → SKIP.

4

Risk score

Solo sin veto. Feature nueva +3 · datos dinámicos +3 · AC-light +2 · esfuerzo +2 · >5 comentarios +1…

5 · Escaneo de viabilidad de datos (solo HIGH)

Lectura de los mapas de datos y API (bun run context:map) y del master-test-plan, sin queries ni API calls. Si el modelo de datos no soporta los ACs → flag DATA-FEASIBILITY-RISK (suave: no bloquea, se vuelve pregunta crítica al PO).

El embudo va en orden estricto: tipo antes que label, label antes que veto, veto antes que score. El rechazo ruidoso ES valor: a menudo revela que el tablero está mal etiquetado. La frescura sale de la label fechada, nunca del timestamp updated de la issue (cualquier comentario lo resetea).

phase 1: el veto vence al score · gate de candidatos

El juicio anula la aritmética, y tú apruebas el set

ScoreNivelProfundidad de refinamiento
0-3LOWSKIP: PO/Dev escriben los ACs sin QA
4-7MEDIUMRefinamiento estándar (Fases 1-3 + outlines)
8+HIGHExtendido: más caza de ambigüedades y edge cases; set de preguntas ampliado

El score es orientativo

El usuario puede rescatar una LOW si huele complejidad oculta. Y el VETO cortocircuita: una Story de refunds es refinamiento obligatorio aunque puntúe 2; un retoque de CSS es skip aunque toque cinco archivos.

GATE: presenta la tabla y ESPERA el OK

Phase 1 termina con una tabla ranqueada: Accepted (riesgo · score · veto override · data-feasibility), Rejected (no-Story, con motivo), Skipped (LOW), Already Reviewed (skip/refresh?), orden recomendado y preguntas abiertas.

No se refina nada hasta que el humano confirme el set. Puede vetar Stories, rescatar LOWs o cambiar el orden. La lista aceptada final se persiste en progress.md, dentro del entry de Phase 1.

Tras el OK, por cada Story aceptada: find-or-create de la subtask [QA] Shift-Left Review con assignee = self desde el create. Nace en {{jira.status.subtask.active}} (status ACTIVE) y ahí queda hasta Phase 3; si ya existía cerrada, se reabre con reactive. Sin work type subtask en el catálogo → skip con warning, nunca bloquea.

La selección es una propuesta y el humano decide. Este gate mantiene al humano dirigiendo el lote, con el mismo patrón que el Story Explanation gate de sprint-testing. La subtask hace visible en el tablero el trabajo pre-sprint de QA y después recibe las anotaciones largas, para que la Story quede limpia.

phase 2: refinement · un subagente por story, secuencial

Refinement: el playbook, en alcance outline

Reuso deliberado: la mayor parte de la lógica vive en sprint-testing/references/acceptance-test-planning.md §Fases 1-3; el subagente la cita y aplica el delta shift-left. Secuencial por diseño: presentas cada resumen al usuario antes de despachar la siguiente Story.

Corre (alcance outline)

  • Fase 1 · Critical Analysis: contexto negocio + técnico; lecturas de código LIGERAS (es viable?), sin reproducción
  • Fase 2 · Story Quality Analysis: el corazón (siguiente slide)
  • Fase 3 · Refined ACs: Given/When/Then con datos específicos
  • Fase 4 · outlines: solo NOMBRES + coverage estimate (guía la estimación del PO)
  • Fase 5 · edge cases: solo nombres + criticidad
vs

Difiere o prohíbe

  • Tablas de parametrización, test-data JSON, recetas Faker → in-sprint (/sprint-testing)
  • Creación de TCs → /sprint-testing o Documentation (/test-documentation), según la modalidad
  • Mutaciones Jira → las hace Phase 3, nunca el subagente
  • Ejecución: smoke, queries DB, API calls → NADA corre
  • Git: sin branch ni commit, Jira es canónico
  • Carpeta evidence/: no hay nada que capturar
La disciplina outline separa shift-left del diseño de tests ejecutable: títulos de outline y conteo de cobertura, nunca los datos. El ATP que se escribe ya es el real, en madurez outline. Generar recetas de Faker ahora sería trabajo desperdiciado que se rehace in-sprint.

phase 2: story quality analysis + doctrina de diseño

El corazón: lo que la Story calla

Qué cazas (Fase 2 del playbook)

  • Ambigüedades: ubicación + pregunta a PO/Dev + impacto en testing + aclaración sugerida
  • Gaps: AC / regla de negocio faltante, por qué es crítico, riesgo si se omite
  • Edge cases no escritos: escenario + comportamiento probable + criticidad
  • Contradicciones: "la descripción dice X pero el AC3 dice Y", explícito
  • Testeabilidad: Yes / Partial / No, listando cada AC vago o dependencia no aislable

Toolkit: refinement-questions.md, catálogo por arquetipo (auth, money, search, state machine, integración, RBAC).

Doctrina de diseño (vinculante)

  • Los ACs son el PISO: el refinamiento empuja más allá del happy path
  • 1:N por defecto: un AC no trivial implica varios outlines; colapsar a 1 exige justificación escrita "trivially atomic"
  • Técnica por gatillo: rangos → BVA · estados → State-Transition · condiciones que interactúan → Decision Table · 3+ factores → Pairwise
  • Todo escenario inferido lleva el marcador NEEDS PO/DEV CONFIRMATION, textual, hasta Jira
  • Una Story limpia es resultado válido: cero preguntas forzadas; relleno y sub-derivación son AMBOS fallos
Aquí es donde el shift-left crea valor: el PO todavía puede actuar. Cada ambigüedad cazada es un defecto de producción borrado antes de nacer, y cada gap es también un outline que falta.

phase 2: el buffer de staging + gate por story

shift-left-refinement.md y tu OK por Story

shift-left-refinement.md: esqueleto + ejemplo
├─ Phase 1 · Critical Analysis
├─ Phase 2 · Story Quality Analysis   ← el corazón
├─ Phase 3 · Refined ACs
│   Given user with active OTP <5 min
│   When  submits code "000000" (wrong)
│   Then  UI "Invalid code" · API 401 · DB no session
│   NEEDS PO/DEV CONFIRMATION ← si fue inferido
├─ Phase 4 · Test Outlines (pre-sprint) ← nombres + coverage
├─ Phase 5 · Edge Cases (pre-sprint)    ← nombres + criticidad
├─ Story Quality Assessment · Critical Questions for PO
├─ Technical Questions for Dev · Suggested Improvements
└─ Data feasibility flags · Recommended testing strategy
  • Buffer [LOCAL], no entregable. Se escribe a mano en la carpeta PBI de la Story, bajo .context/PBI/** (gitignored): existe solo en la máquina que corrió el lote. Phase 3 publica su body completo en el campo ATP y desde ahí la copia canónica es la de Jira.
  • Nada depende de que esté en disco. /sprint-testing cortocircuita leyendo el acceptance-test-plan.md SINCRONIZADO, nunca este archivo. Los espejos Jira (story.md, acceptance-criteria.md) solo los genera el sync.
  • Bootstrap: si la carpeta PBI no existe, el subagente la crea con un context.md mínimo. Sin evidence/.
  • Convención de outline: Should <behavior> <condition>, agrupados por tipo con tabla de coverage (Positive / Negative / Boundary / Integration).
  • Retorno al orquestador: JSON compacto con quality, #gaps, #preguntas PO/Dev, outlines por tipo, flags.
  • GATE: el orquestador presenta el resumen, espera tu OK, registra el checkpoint Phase 2.<n> en progress.md y recién entonces despacha la siguiente Story.
El orden de secciones es estructural: se convierte en el bloque que el PO lee en Jira. El checkpoint por Story permite retomar un lote a la mitad sin repetir trabajo. Si el cortocircuito de sprint-testing dependiera de este archivo local, en cualquier otra máquina se degradaría en silencio a un re-run completo.

phase 3: handoff · 6 mutaciones jira por story (vía /acli)

Handoff: seis mutaciones, en orden

1

ACs → campo

Refined ACs al campo acceptance_criteria. Fallback si no existe: comentario "## Acceptance Criteria". Verifica con re-sync.

2

Descripción

Append de "QA Refinements (Shift-Left Analysis)": edge cases + reglas aclaradas + preguntas. Leer primero, NUNCA sobrescribir.

3

ATP

Puebla el campo acceptance_test_plan con el ATP pre-sprint (madurez outline), field-first: el Test Plan item "ATP: {STORY-KEY}: {título}" NO se crea aquí; lo crea /sprint-testing Planning desde este MISMO campo, sin variante de título. Fallback si el campo no existe: comentario "## Acceptance Test Plan (ATP)".

4

Comentario

UN comentario de handoff: puntero al campo (@PO / @Dev-lead solo si están en project.yaml). Body completo inline SOLO si el campo no existe.

5

Labels + QA Assignee

shift-left-reviewed + shift-left-{YYYY-MM-DD}. qa_assignee = self, read-before-write, vía REST PUT (acli no escribe customfields).

6

Transición + subtask + traza

analyze → estimate y STOP en Estimation. La subtask [QA] Shift-Left Review recibe las anotaciones exhaustivas de sesión y se cierra con complete → Close (la Story queda limpia). Re-sync: el ATP aterrizó en el campo y el comentario es un PUNTERO; el body inline solo aplica en modo fallback. test-documentation modo repair-traceability lo audita después.

Ni ADF a mano ni Markdown crudo

Los cuerpos rich-text (ATP, ATR, descripción del Test) se escriben en Markdown, se convierten y validan con el conversor .agents/skills/acli/scripts/md-to-adf.ts, y lo que se publica es el ADF JSON resultante; por la vía CLI, acli nunca convierte Markdown solo. Markdown crudo se ve en Jira con # y ** literales; ADF artesanal se aleja del contenido que audita repair-traceability.

Secuencial, una Story a la vez, para que revises el estado de Jira antes de la siguiente mutación. El subagente devuelve un log por Story: atp_container (campo o comentario fallback), subtask, labels, transiciones, light_verifier y trace_status.

phase 3: guardrails de transición + resume

STOP en Estimation, y todo re-ejecutable

Status actualAcción
Backloganalyze → Shift-Left QA, luego estimate → Estimation
Shift-Left QAsolo estimate
Estimationnada: ya está en el objetivo
Más allá (Ready For Dev…)SKIP + warning: el refinamiento aterriza igual, el workflow no se toca

La estimación es del PO + Dev lead

QA jamás avanza estimate → ready_for_dev ni compromete la Story a un sprint. Y NUNCA se transiciona a Estimation sin el ATP pre-sprint poblado: ese ATP es lo que hace estimable a la Story (anti-patrón L5).

Resume seguro: cada paso es idempotente

  • Sección ya en la descripción → skip · campo ATP → overwrite OK · comentario ya existente → skip
  • Labels son set-based · transición lee el status antes de aplicar
  • Subtask [QA] Shift-Left Review: se busca por título exacto, nunca se duplica; si ya está en Close no se re-transiciona y las anotaciones van como comentario nuevo (sin subtasks en el proyecto → skip con warning)
  • Error de subagente → STOP, estado parcial reportado, opciones retry / skip / abort. Sin auto-rollback: las mutaciones quedan registradas en el batch report para retomar.
Dos innegociables: parar en Estimation (la estimación es decisión de negocio) y ambos labels siempre; sin ellos se rompe el cortocircuito de /sprint-testing el próximo sprint.

phase 3: cierre de cada story · light stage verifier + definition of done

Cada Story cerrada se verifica línea por línea

light stage verifier: líneas propias de Shift-Left
[ ] Story en {{jira.status.story.estimation}}
    vía analyze → estimate, y STOP ahí
    (ya más allá: refinamiento sí, transición no)
[ ] Subtask [QA] Shift-Left Review en Close
    vía complete
    (N/A declarado si no hay work type subtask)
[ ] Assignee de la subtask = self, desde el create
[ ] Todo slug sin mapear pasó por el fallback §4
    (se preguntó; nunca un skip en silencio)
# + las líneas comunes del template:
# artifact-lifecycle.md §5

Cada línea es YES o un N/A declarado con su motivo; una línea en blanco cuenta como fallo. Un NO deja el stage en NEEDS REVISION: se arregla o se reporta, nunca se avanza. "Ligero" quiere decir lo que el agente ya hizo, más a lo sumo UNA lectura de la Story.

Definition of Done del stage (stage-gates.md)

El orquestador la verifica contra el reporte del subagente y lo que hay en Jira ANTES de escribir el checkpoint status: completed:

  • ACs refinados en Given/When/Then con datos concretos
  • Gaps, ambigüedades y edge cases como preguntas a PO/Dev
  • Test-Design Checklist aplicado: cada AC no trivial explotado por técnica, o justificación trivially atomic
  • Coverage estimate con el 1:N real, sin conteo minimizado
  • Inferidos marcados NEEDS PO/DEV CONFIRMATION
  • Ninguna entidad TMS creada; label + transición aplicadas
  • Statuses según el lifecycle; light verifier corrido

Status sin mapear: se pregunta, nunca se saltea

Si el proyecto renombró los status y falta un slug (por ejemplo el complete de la subtask), la skill lista las transiciones VIVAS de la issue, hace UNA pregunta con la mejor candidata, dispara el id vivo con tu OK y recomienda bun run jira:sync-workflows. .agents/jira-workflows.json es generado: nunca se edita a mano.

Un stage no termina cuando el subagente devuelve: termina cuando su Definition of Done está cumplida. El verificador ligero existe para atrapar lo que se saltó en silencio, sin re-auditar todo lo que se acaba de crear.

phase 3: cierre de sesión · batch report + archive

El batch report: lo único que el grooming lee

Qué agrega

  • Metadatos de sesión: candidatos / aceptadas / rechazadas / saltadas / refinadas
  • Línea por Story: riesgo · #gaps · #preguntas PO · #tech Qs · #outlines · status final · traza
  • Preguntas al PO dedupeadas y ranqueadas por cuántas Stories bloquea cada una
  • Distribución de riesgo + bloqueadores DATA-FEASIBILITY con pre-work requerido
  • Orden recomendado de sprint planning (riesgo + dependencias)

Adónde va, y el cierre

  • Siempre: .session/shift-left-testing/<batch-id>/batch-report.md
  • Si TODAS las Stories comparten epic padre → se publica como comentario en ese epic; si no, se entrega inline al usuario
  • Nunca se publica en cada Story: el comentario per-Story ya existe (paso 4)
  • Entry final en progress.md → Archive: la carpeta de sesión se mueve a .session/.archive/
  • Cierre de memoria: mem_session_summary con el resumen + ruta del archive
"Esta pregunta bloquea tres Stories" es exactamente cómo un PO quiere triagear. Si publicar en el epic falla, no aborta: el reporte local es autoritativo.

cierre de sesión: session footer + mejoras propuestas

Lo que se usó, dicho en el chat

session footer · framing Execution (ejemplo)
### Session Footer: Tools & Testing Levels
Skills loaded: shift-left-testing, acli
MCPs used: none
CLIs used: acli, bun (jira:sync-issues, context:map)
Testing levels touched:
- UI/E2E: none (pre-sprint, la feature no existe)
- API/Integration: none
- Database: none
- Unit: none
Refinements proposed: 1 →
  .session/shift-left-testing/<batch-id>/refinements.md
  • Capturas: cada ruta se muestra apenas la captura existe, y al cierre va la lista consolidada con rutas relativas verificadas en disco. En shift-left lo normal es no tener ninguna, porque no hay evidence/.
  • Framing Execution: niveles de la pirámide ejercitados, con "none" explícito en cada nivel esperado y no tocado. Nunca se rellena cobertura que no ocurrió.
  • Lo compila el orquestador UNA vez: cada subagente reporta sus campos (skills, MCPs, CLIs, niveles, capturas) y el footer se arma al final.
  • Solo en el chat: nunca en un comentario de Jira ni en un ATR.
  • Refinements proposed: las lecciones de la sesión se PROPONEN en refinements.md y nunca se aplican a la skill en vivo (skill-refinement-protocol.md).

Si la que falló es la skill

Un paso equivocado, un verificador faltante o una regla vieja se reporta upstream según agentic-qa-core/references/upstream-feedback.md: borrador redactado en local, se publica solo con tu OK explícito y se verifica con gh issue view.

El footer es la última línea del verificador ligero: sin él, el stage no está cerrado. Es el lugar donde se ve qué niveles de la pirámide quedaron en "none" y si la sesión dejó mejoras propuestas para revisar.

opcional · lotes grandes · fleet seam

Un worker por Story, el mismo gate

El refinamiento es secuencial por defecto y así se queda. El fleet (una sesión de worker persistente por Story y un conductor que junta sus reportes) entra solo cuando el usuario lo pide explícitamente para un lote grande.

Topología: el mismo checkout

La skill solo escribe en Jira: sin código, sin branch, sin índice git en disputa. Un worktree por Story sería puro costo.

launch.txt, siempre

El conductor escribe .session/shift-left-testing/<batch-id>/launch.txt, una línea autocontenida por Story, haya o no transporte de orquestación en la máquina. Lanzar, supervisar y cerrar esas sesiones es de orca-orchestration; si nada puede lanzarlas, una persona pega esas líneas.

El OK por Story se muda al conductor

El conductor presenta el resumen de cada worker a medida que llega y espera el mismo approve / veto antes del handoff de Phase 3 de esa Story. Un fleet que se saltea esto ya no está corriendo esta skill.

Un escritor por Story

Dos workers nunca refinan la misma Story, y toda escritura Jira de una Story es de su worker. El batch report y el comentario en el epic quedan en el conductor.

Regla de silencio

Cuando la máquina no tiene transporte de orquestación, la skill no lo menciona: no aparece en el preflight, ni en el batch report, ni en el chat. El launch.txt queda escrito igual.

La paralelización no compra velocidad a costa del humano: el gate por Story sigue existiendo, solo cambia quién lo presenta. Por defecto la skill corre secuencial, que es el ritmo de un grooming en equipo.

cómo invocar · qué sigue en el pipeline

Dispara la skill, y qué viene después

invocación · tres hosts
# Claude Code: slash + la lista de Stories como args
> /shift-left-testing UPEX-100,101,102
# OpenCode y Codex: la skill se nombra en prosa
> cargá la skill shift-left-testing para UPEX-100,101,102
# sin IDs, arma la JQL de backlog:
> groom the backlog

Sin modos: la skill no tiene ## Mode routing ni modo single-issue. Los args son la lista de Stories; para una urgente, una lista de largo 1.

Refined ACs en Jira ATP pre-sprint en el campo 2 labels Status: Estimation Subtask en Close batch-report.md
Después necesitas…Skill
La Story llega a Ready For QA/sprint-testing: lee los labels (<30 días) y el ATP publicado en el campo, y solo con los dos cortocircuita sus fases de planning
TCs formales + ROI, cuando la Story shippea/test-documentation (Documentation)
Código de test automatizado/test-automation (Automation) · luego /regression-testing (Regression)
Falta contexto de negocio/project-discovery + /project-context (modos data / e2e / api y test-plan)
Revisión adversarial del refinamiento (opcional)/judgment-day, nunca auto-invocado

← → navegar · O overview · S presentador · N notas · F pantalla completa

Recuerda tres cosas: prevenir antes que detectar; el veto vence al score y la señal vence al volumen; un comando conduce las tres fases con un gate humano en cada paso de consecuencia. El label que pones en el refinamiento le ahorra trabajo al equipo el próximo sprint.
/shift-left-testing · Shift-Left · Pre-sprint QA
← → navegar · O resumen · S presentador · N notas · F pantalla