AGENTIC QA · WORKFLOW SKILL · STAGE 0

/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 entrega un ATP DRAFT — los defectos se previenen en los requisitos, no se detectan tras implementar.

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. Args-as-answers · probe, don't assume. Un solo checklist de gaps; RED bloqueante → STOP.
RED → arregla .env + reinicia
0Session Init
Resume check · modalidad TMS A/B · carga /acli (+ /xray-cli opt-in) · verifica .context/ · resuelve candidatos · crea .session/<batch-id>/
falta contexto → /project-discovery
1Selection
Sync-read por candidato → filtro de tipo → frescura de label → veto → risk score → tabla ranqueada de candidatos
GATE · OK del usuariono-Story → rechazo en voz alta
2Refinement ×N
1 subagente por Story, SECUENCIAL · playbook en modo DRAFT → shift-left-refinement.md + resumen por Story
GATE · OK por Storyerror → retry / skip / abort
3Handoff ×N
6 mutaciones Jira por Story · labels · qa_assignee · transición Backlog → Shift-Left QA → Estimation y STOP
campo ausente → comment fallbackModalidad A → Test Plan opt-in
✓Batch report
Agrega preguntas PO/Dev (dedupe) → batch-report.md → comment en el epic padre si comparten uno · archiva la sesión
→ /sprint-testing · cortocircuito

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

Memoriza esta columna: Preflight → Init → Selection → Refinement → Handoff → Batch report. Cada fila es una sección del deck. 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 trackerREQUIREDbun run jira:check — todo el output del refinamiento aterriza en Jira
Modalidad TMS resueltaREQUIREDA: Xray · B: Jira-native — decide dónde vive el ATP DRAFT
/xray-cli + creds XRAY_*OPTIONALSolo si el usuario opta por un Test Plan por Story (default: NO)
Contexto de negocioREQUIRED.context/business/* + master-test-plan.md — sin ellos, preguntas vagas al PO
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.

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. Probe de 4 pasos (A: Xray · B: Jira-native). 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. 4 archivos .context/ verificados; si falta uno → STOP → /project-discovery.
  • 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

# el entregable por Story vive en su carpeta PBI:
.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 <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 business-data-map / business-api-map / master-test-plan — sin queries, sin 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.

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 se persiste en plan.md §Inputs y se registra el checkpoint en progress.md.

La selección es una propuesta, no una decisión. Este gate mantiene al humano dirigiendo el lote — el mismo patrón que el Story Explanation gate de sprint-testing.

phase 2 — refinement · un subagente por story, secuencial

Refinement: el playbook, en modo DRAFT

Reuso deliberado: ~70% 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 DRAFT)

  • 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 en el TMS → Stage 4 (/test-documentation)
  • Mutaciones Jira → las hace Phase 3, nunca el subagente
  • Ejecución: smoke, queries DB, API calls → NADA corre
  • Git: sin branch, sin commit — Jira es canónico
  • Carpeta evidence/ — no existe nada que capturar
La disciplina DRAFT separa shift-left del diseño de tests real: títulos de outline y conteo de cobertura, nunca los datos. 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, no el techo — 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. Un gap no es solo una pregunta — es un outline faltante.

phase 2 — el entregable + 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 (DRAFT)    ← nombres + coverage
├─ Phase 5 · Edge Cases (DRAFT)       ← nombres + criticidad
├─ Story Quality Assessment · Critical Questions for PO
├─ Technical Questions for Dev · Suggested Improvements
└─ Data feasibility flags · Recommended testing strategy
  • Archivo NON-Jira en la carpeta PBI de la Story — se escribe a mano. 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: 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.

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 DRAFT

Default: campo acceptance_test_plan con el body completo. Modalidad A + opt-in: Test Plan "ATP: … (Shift-Left DRAFT)" bajo el epic QA Master Test Plan + link a la Story.

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 + traza

analyze → estimate y STOP en Estimation. Verifica el espejo campo ↔ comentario byte a byte — fix-traceability lo audita después.

Nunca ADF a mano

El body se autoría en Markdown local y /acli lo convierte en su ruta md-to-ADF. ADF artesanal rompe el espejo byte a byte.

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, labels, transiciones, 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 ATP DRAFT populado — el DRAFT 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
  • Test Plan (Modalidad A): busca por título antes de crear
  • 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 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.

cómo invocar · qué sigue en el pipeline

Dispara la skill — y qué viene después

claude-code
> /shift-left-testing UPEX-100,101,102
# o en lenguaje natural:
> groom the backlog
> shift-left these stories
> pre-sprint QA on these 5 stories
Refined ACs en Jira ATP DRAFT 2 labels Status: Estimation shift-left-refinement.md batch-report.md
Después necesitas…Skill
La Story llega a Ready For QA/sprint-testing — lee shift-left-reviewed (<30 días) y cortocircuita sus fases de planning
TCs formales + ROI, cuando la Story shippea/test-documentation — Stage 4
Código de test automatizado/test-automation — Stage 5 · luego /regression-testing — Stage 6
Falta contexto de negocio/project-discovery + /business-*-map + /master-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 hoy le ahorra trabajo al equipo el próximo sprint.
/shift-left-testing · Stage 0 · Pre-sprint QA
← → navegar · O resumen · S presentador · N notas · F pantalla