skills-io — Flujo E2E · inputs & outputs

upex@galaxy — skills-io · flujo E2E · historia → refinamiento → dev → testing

zsh

skills-io · cómo leer este deck

Una historia, dos repos, un pipeline

Cada skill del ecosistema se comporta como un proceso de terminal: recibe stdin (archivos de contexto, campos de Jira), depende de otras skills (deps) y emite stdout (artefactos, issues, transiciones). Este deck documenta ese contrato de inputs/outputs, fase por fase.

ANTES · Contexto del proyecto qa-boilerplate · una vez, y cada vez que el producto cambia ├─ project-discovery mapas de dominio + infra · project-config.md ├─ test-framework-adaptation KATA adaptado al stack del producto └─ project-context mapas de datos · API · E2E · Master Test Plan └─ context skills bun run context:map <slug> · las lee cada fase │ ▼ FASE 1 · Historia dev-boilerplate · product-management │ ▼ FASE 2 · Refinamiento ⟲ loop dev (INVEST) ⇄ qa (shift-left-testing) │ ▼ FASE 3 · Implementación dev-boilerplate · sprint-development │ ▼ FASE 4 · Testing qa-boilerplate ├─ 4a sprint-testing QA manual por ticket ├─ 4a exploratory-testing Execution sin ticket · alimenta 4b ├─ 4b test-documentation TMS + ROI ├─ 4c test-automation KATA · solo verdict Candidate └─ 4d regression-testing release gate GO / NO-GO │ ▼ FASE 5 · Producción Observation · L4 └─ rutina agéntica, sin skill SLOs · error budget · realimenta el próximo shift-left TRANSVERSAL cruza todas las fases · pestaña «transversal» ├─ revisión pr-review-lead · judgment-day ├─ flota y relevo orca-orchestration (opcional) · session-handoff └─ git · evidencia · sync git-flow-master · bug-screenshot-annotation · [SYNC] lista completa de skills .agents/skills/REGISTRY.md

Observation está declarado, no implementado: sin skill propio (ver .agents/skills/ para el estado). Aparece acá para que el mapa no mienta sobre dónde termina el sistema.

skillsqué skills y references carga la tarea

stdin ←lo que la skill necesita leer antes de actuar

stdout →lo que la skill produce (archivos, issues)

jira ⇄campos, labels y transiciones que toca

Regla de oro [SYNC]: todo .md que refleja un campo de Jira es solo lectura — se regenera con bun run jira:sync-issues. Jira es la fuente de verdad; el filesystem es cache.

Navegación: pestañas arriba · ←/→ cambia de pestaña · 1-9 salto directo · imprimir muestra todo en vertical.

fase 1 · repo dev-boilerplate

Crear la Historia

Skill de entrada: product-management. Del PRD/SRS al backlog en Jira.

upex@galaxy ~/fase-1$ skill product-management --ref product-backlog-seed.md

Backlog seed inicial (solo primera vez)

dev

skills

product-managementacli · [ISSUE_TRACKER_TOOL]agentic-dev-core (session-management · skill-composition-strategy)

stdin ←

.context/PRD/ (mvp-scope · user-personas · user-journeys) · .context/SRS/ (functional-specs · non-functional-specs) · los 3 business maps · .context/PBI/epic-tree.md · .agents/project.yaml + catálogos jira-*.{yaml,json}

stdout →

Epics + Stories creados en Jira bajo {{PROJECT_KEY}} → bun run jira:sync-issues pull materializa epic-tree.md + epics/EPIC-<KEY>-<slug>/ · sesión en .session/product-management/seed/{plan.md, progress.md}

Épica / historia individual

dev

skills

product-management (references/epic-creation.md)

stdin ←

Lista de lectura canónica (igual que 1a) + metas del PRD para trazabilidad

stdout →

Epic + stories hijas en Jira · sync → epic.md + carpetas de stories · memoria con topic_key pbi/{epic-slug}/epic (UPSERT)

Redacción de AC en Gherkin

dev

skills

product-management (references/acceptance-criteria.md)

stdin ←

Campo actual {{jira.acceptance_criteria}} · PRD/SRS como fuente de verdad

stdout →

{{jira.acceptance_criteria}} reescrito en bloque ```gherkin``` · sync → stories/STORY-<KEY>-<slug>/acceptance-criteria.md (ningún spec.md por story: spec.md solo existe bajo test-specs/ como plan de batch de automatización, con TCs referidos por clave Jira)

Enumeración de edge cases

dev

skills

product-management (references/edge-cases-enumeration.md)

stdin ←

Spec de la feature/historia · PRD/SRS

stdout →

stories/STORY-<KEY>-<slug>/edge-cases.md · los de alta criticidad se promueven a {{jira.acceptance_criteria}}

exit 0 → historia creada en Jira · status Backlog

fase 2 · loop entre dos repos

Refinamiento dev ⇄ qa

La historia rebota entre INVEST (dev) y Shift-Left QA (qa) hasta que los ACs quedan firmes.

Refinamiento INVEST

dev

skills

product-management (references/story-refinement.md)

stdin ←

Historia existente en Jira · .context/PRD/ · business/domain-glossary.md

stdout →

Historia validada INVEST · notas 3-amigos (sin archivo — no es session-managed) · checklist ready-for-dev confirmado

upex@galaxy ~/fase-2$ skill shift-left-testing --batch UPEX-100,UPEX-101,UPEX-102

Preflight (gate): acli autenticado + bun run jira:check. No produce output — solo bloquea si falla.

Init / Resume de sesión

skills

agentic-qa-core (session-management)test-documentation §Phase 0 (modalidad TMS)acli (xray-cli no se usa pre-sprint: ATP field-first)

stdin ←

Los 3 business maps · master-test-plan.md · jira-workflows.json · jira-required.yaml · sesión previa si existe

stdout →

.session/shift-left-testing/<YYYY-MM-DD>-<descriptor>/ con {plan.md, progress.md, candidates.md, batch-report.md}

Selección de candidatas

skills

references/backlog-selection.mdacli

stdin ←

bun run jira:sync-issues get <KEY> o jql "<JQL>" → issueType · status · labels (shift-left-reviewed) · priority · sprint · epic padre

stdout →

candidates.md (tabla ranqueada) · lista aceptada → plan.md §Inputs · por Story aceptada: subtask «[QA] Shift-Left Review» find-or-create → In Progress (skip + warning si el catálogo no tiene work type subtask)

Refinamiento (loop por historia)

skills

sprint-testing/references/acceptance-test-planning.md §1-3+4refinement-playbook.mdatp-outline-template.mdrefinement-questions.mdtest-design-doctrine.md — MANDATORIO

stdin ←

story.md · acceptance-criteria.md · comments.md sincronizados · contexto de negocio (P0)

stdout →

stories/STORY-<KEY>-<slug>/shift-left-refinement.md por historia (artefacto local, NO Jira)

Handoff a Jira

skills

references/handoff-protocol.mdaclidefect-management-doctrine.mdtraceability-linking.md

stdin ←

shift-left-refinement.md · acceptance-criteria.md re-sincronizado

jira ⇄

Campos: {{jira.acceptance_criteria}} · {{jira.acceptance_test_plan}} field-first en AMBAS modalidades (NO Test Plan item pre-sprint — lo crea sprint-testing Planning desde el field) · sección «QA Refinements (Shift-Left Analysis)» en la description · {{jira.qa_assignee}} solo si está vacío · Labels: shift-left-reviewed + shift-left-{{YYYY-MM-DD}} · Transiciones: Backlog → Shift-Left QA → Estimation · Comentario: puntero al campo ATP (fallback sin custom field: cuerpo bajo ## Acceptance Test Plan (ATP)) · subtask «[QA] Shift-Left Review»: anotaciones exhaustivas de sesión + transición complete a Close

loop 2a ⇄ 2b hasta ACs firmes → exit 0 → status Estimation (el equipo estima y la pasa a Ready For Dev)

fase 3 · repo dev-boilerplate

Implementación sprint-development

Mega-orquestador por stages. Las references adr-doctrine.md y session-management.md viven en agentic-dev-core/references/.

Planning

dev

skills

story-plan.md · feature-plan.mdagentic-dev-core (adr-doctrine.md · session-management.md)acligit-flow-master (solo gate de riesgo alto)/dev-roadmap (si falta)

stdin ←

.agents/project.yaml + catálogos jira · master-implementation-plan.md · dev-roadmap.md · domain-glossary.md · stories/STORY-*/context.md · .context/ADR/ · DESIGN.md · campos {{jira.acceptance_criteria}} + {{jira.acceptance_test_plan}}

stdout →

Plan escrito al campo spec_implementation_plan (o comentario fallback) → sync-back implementation-plan.md · ADR opcional ADR-NNNN-<slug>.md (status Proposed)

jira ⇄

Transición: Ready For Dev → In Progress

Implementation

dev

skills

implement-story.md · bug-fix-workflow.md · continue-implementation.md · code-standards.mdunit-testing (TDD · mid-stage)Playwright CLI (live-UI check)

stdin ←

implementation-plan.md sincronizado · código fuente · code-standards.md · .env

stdout →

Commits atómicos · bugs/BUG-<KEY>-<slug>/bug-fix.md (solo bugfix) · progress.md por chunk · sin transición Jira

Code Review

dev

skills

git-flow-master (abre PR)review-pr.md · spec-compliance-matrix.md · fix-issues.md

stdin ←

Diff del PR · DESIGN.md + master-design-plan.md · ACs de la historia

stdout →

PR feat({{PROJECT_KEY}}-N): <short> · review.md · compliance-matrix.md

jira ⇄

Transición: In Progress → In Review

Staging Deploy

dev

skills

git-flow-master (gh pr merge --squash)vercel-cli / CIacli (asignación)

stdin ←

PR mergeado · estado del CI · .env

stdout →

Merge a staging → auto-deploy · comentario de notificación a QA (PR URL + @-mention)

jira ⇄

Transición: In Review → Ready For QA · assignee = QA owner (quien hizo el shift-left; si no se identifica, queda sin asignar)

Prod Deploy (gateado)

dev

skills

pre-deploy-checklist.md · production-deploy.md · rollback-plan.md

stdin ←

Confirmación QA-green en staging + aprobación explícita de negocio

stdout →

Deploy a producción + ventana de monitoreo · sin transición Jira estándar (solo status interno del sprint-report)

upex@galaxy ~/fase-3$ ps --nested

unit-testing — stdin: función bajo test · tests hermanos · callers · config del runner (vitest.config.ts/jest.config.ts) · helpers/fixtures (prereq: test command en package.json). stdout: *.test.ts/*.spec.ts — sin Jira, sin git.
git-flow-master — stdin: git status/branch/log/diff · bloque git_strategy: en .agents/project.yaml. stdout: branch {prefix}/{ISSUE-KEY}-{slug} · commit {type}({KEY}): {desc} · PR con body templado.
judgment-day (opcional) — stdin: diff/PR bajo revisión · AGENTS.md · REGISTRY.md. stdout: veredicto en chat APPROVED ✅ / ESCALATED ⚠️ (detalle en pestaña transversal).

exit 0 → historia en Ready For QA

fase 4a · repo qa-boilerplate

Sprint Testing manual por ticket

Skill /sprint-testing: Planning · Execution · Reporting (históricamente Stages 1-3).

Planning

skills

test-design-doctrine.md — MANDATORIOdefect-management-doctrine.md — MANDATORIOacli / xray-clishift-left-testing (short-circuit solo con el ATP publicado como evidencia, nunca por las labels solas)

stdin ←

story.md · acceptance-criteria.md · acceptance-test-plan.md · comments.md · mapa de dominio (business-domain-context) · master-test-plan.md · campos {{jira.qa_assignee}} · AC · priority · label shift-left-reviewed

stdout →

Primer ticket del sprint: STP «STP: Sprint#{N}: {objetivo}» find-or-create · orden Set-first: Test Set «ATS: {US}: {título}» → epic QA Test Artifacts con link ATS→Story (el link de coverage) → Test Plan «ATP: {STORY}: {título}» desde el field del shift-left → epic QA Master Test Plan → Test Execution «ATR: …» con --environment siempre (gate: sin environment no hay ATR) · listas de Plan/Exec derivadas de la membership del ATS · TCs: en jira-xray crea los Test de los outlines y los ejecuta en el ATR; en jira-native solo outlines (lo decide testing.tc_creation_stage) · triage de riesgo en bugs: 0-3 LOW · 4-7 MEDIUM (pregunta) · 8+ HIGH

nota

kata-manifest.json se vuelve load-bearing recién en el hand-off de Reporting → test-automation, no en Planning.

Execution (trifuerza UI · API · DB)

skills

playwright-cli (UI)OpenAPI MCP → bun run api:login → curl (API)DBHub MCP (DB)bug-screenshot-annotation (bugs visuales)

stdin ←

ATP de Planning · test-session-memory.md

stdout →

Evidencia en stories/STORY-*/evidence/ · imágenes anotadas · PASS/FAIL en test-session-memory.md (o Test Run) · Test nuevo solo si hay defecto reproducible

Reporting

skills

acli / xray-clidefect-management-doctrine.md

stdin ←

Evidencia de S2 · ATP · campos {{jira.severity}} (deriva priority) · {{jira.qa_assignee}}

jira ⇄

Resultados PASS/FAIL al ATR «ATR: {STORY}: Story Testing» creado en S1 (epic QA Test Artifacts) · STP actualizado (scope + progreso del ticket) · comentario QA (PASS/FAIL) · transición a qa_approved o blocked · Bug/Defect/Improvement → epic QA Defect Management con components + link a la Story + qa_assignee self-set · al cierre del sprint (batch-close): STR «STR: Sprint#{N}: Regression Testing» find-or-create como recap

exit 0 → ticket qa_approved (o blocked con bugs filed)

Execution sin ticket (/exploratory-testing)

skills

adversarial-verification.md — MANDATORIOdiscovery-driven-doctrine.md — MANDATORIOplaywright-climkdacli

stdin ←

gap list de project-context coverage (opcional) · kata-manifest.json · Tests del módulo en el TMS · mapas de negocio · master-test-plan.md · module-context.md

stdout →

charter.md · findings/FNN-*.md · candidate-scenarios.md con cada candidato NEW / WEAK / COVERED y oracle: observed hasta que una persona confirma

jira ⇄

Solo con aprobación: bugs bajo QA Defect Management · Tech Story de cobertura bajo QA Test Repository · sección ## Module Context (QA) de la Epic

fase 4b · repo qa-boilerplate

Documentación TMS + ROI

Skill /test-documentation: del testing manual al repositorio de test cases.

Detección de modalidad

stdin ←

.agents/project.yaml — testing.tms_cli (candidato) · evidencia: la API de Xray responde vía xray-cli; los work types solos nunca deciden · pregunta solo si ninguna de las dos decide

stdout →

Decisión de modalidad → carga xray-cli o acli · escrita a plan.md §Inputs

Analyze

skills

test-design-doctrine.mddefect-management-doctrine.md

stdin ←

Todos los archivos sincronizados de la historia · ATP/ATR · implementation-plan/código (data-testid=, rutas, endpoints) · mapa de dominio (business-domain-context)

stdout →

Lista de escenarios candidatos (sin escritura en el TMS todavía)

Prioritize (ROI)

stdin ←

Escenarios de P1 + señales de bugs previos

stdout →

Veredicto por escenario: Candidate (→ automation) · Manual (terminal) · Deferred (terminal)

Document

skills

acli / xray-clitms-architecture.md · traceability-linking.md

stdin ←

qa.qa_epics.test_repository_epic · jira-required.yaml · jira-fields.json · jira-workflows.json

jira ⇄

Test issues (TC) creados (jira-native) o promovidos + enriquecidos (jira-xray: ya los creó sprint-testing), según testing.tc_creation_stage: description con template TC · labels · Test Status · membership TC ∈ ATS = issue link TC→ATS en ambas modalidades (jira-xray suma la membership Xray vía GraphQL) + ATS→Story como link de coverage; TC→Story directo solo last-resort · transición Draft → In Design → Ready → (Manual | In Review → Candidate)

stdout →

Cache local stories/STORY-*/test-cases/{TC-ID}-{slug}.md

exit 0 → TCs trazados en el TMS · los Candidate alimentan la fase 4c

fase 4c · repo qa-boilerplate · solo verdict candidate

Automatización KATA

Skill /test-automation: Plan → Code → Review sobre Playwright + TypeScript.

Plan

skills

test-design-doctrine.md — MANDATORIOkata-architecture.md · typescript-patterns.md

stdin ←

kata-manifest.json (gate anti-duplicación) · tests/components/ · implementation-plan.md + ATP de la historia · api/schemas/

stdout →

test-specs/<scope>/{spec.md, automation-plan.md, atc/*.md} (artefactos locales, NO Jira)

Code

skills

playwright-best-practices — obligatoriaplaywright-cli

stdin ←

Artefactos del Plan aprobado · kata-manifest.json · api/schemas/

stdout →

tests/components/api/{Resource}Api.ts o tests/components/ui/{Page}Page.ts · registro en ApiFixture/UiFixture (los Steps no se registran: import directo) · tests/e2e/{module}/{verbFeature}.test.ts

Review

skills

/pr-review-lead o /judgment-day — REQUERIDOtest-documentation + acli (transición del TC)

stdin ←

Archivos nuevos/modificados de Code

stdout →

kata-manifest.json regenerado (bun run kata:manifest)

jira ⇄

TC Candidate → In Automation (al arrancar Code) → Pull Request (al abrir el PR) → AUTOMATED (cuando el código llega a la rama de producción con CI verde)

exit 0 → ATC en la suite · manifest al día · TC en status AUTOMATED

fase 4d · repo qa-boilerplate · release gate

Regresión GO / NO-GO

Skill /regression-testing: suites vía CI/CD, clasificación de fallos y veredicto de release.

Suite + análisis + veredicto

skills

agentic-qa-core (dispatch · session)xray-cli / acliplaywright-cli (trace)git-flow-master (fallback SDET)

stdin ←

.github/workflows/*.yml · master-test-plan.md · playwright.config.ts · Allure previo (./analysis/previous/) · kata-manifest.json · artefactos CI: merged-allure-results · e2e-failure-evidence · e2e-playwright-report · campos Allure (status, statusDetails, labels[])

stdout →

.context/reports/regression-{env}-{date}.md · Bug/Defect filed (acli workitem create) con severity → priority auto · components · root_cause · error_type · TMS: STP/STR actualizados

score

Veredicto Score/9 → GO ≥7 · CAUTION 4-6 · NO-GO <4

Clasificación de fallos: REGRESSION · FLAKY · KNOWN · ENVIRONMENT · NEW TEST — cada categoría pesa distinto en el score.

exit 0 → decisión de release documentada + issues de regresión creados

reglas que cruzan todas las fases

Notas transversales

Contratos que aplican sin importar en qué fase estés.

⚖

judgment-day

dev + qa

stdin ←

Diff/PR bajo revisión · AGENTS.md · REGISTRY.md

stdout →

Veredicto en chat: APPROVED ✅ / ESCALATED ⚠️ · en la fase de fix sí puede modificar archivos (delega un fix agent) — lo que nunca toca es Jira

nota

Nunca auto-invocado. En la Review de test-automation es uno de los dos verificadores obligatorios (el otro es /pr-review-lead); gate opcional en Code Review (dev) y en el pre-PR de git-flow-master.

✏

bug-screenshot-annotation

stdin ←

Screenshot crudo en evidence/

stdout →

evidence/{KEY}-BUG-{BUG-KEY}-annotated.png · embed opcional como comentario Jira vía jira-attach-media.ts · render 100% local (loopback HTTP + playwright-cli)

⟳

Archivos [SYNC]

dev + qa

regla

Cualquier .md que refleje un campo de Jira es de solo lectura — prohibido escribirlo a mano. Se genera vía bun run jira:sync-issues get / jql / pull. Jira manda; el filesystem es cache.

◆

Los 4 epics QA fijos

jira ⇄

QA Defect Management → bugs / defects / improvements · QA Test Repository → Tests (TC) · QA Master Test Plan → Test Plans (FTP · STP · ATP · RTP) · QA Test Artifacts → Test Executions (STR · ATR · RTR) + Test Sets (ATS · TS:) + Preconditions · nunca un epic de producto: la Story origen viaja por issue-link, el módulo afectado por components (modelo de 3 ejes)

◎

Contexto del producto

skills

project-discoveryproject-contexttest-framework-adaptationiql-context (metodología)

stdout →

Mapas HTML dentro de sus context skills (.agents/skills/<slug>/references/) · .context/project-config.md · Master Test Plan en la descripción del epic QA Master Test Plan

nota

Cada fase los lee con bun run context:map <slug>, nunca el HTML crudo. Si un mapa contradice lo que ves, la context skill propone el cambio y lo aplica con tu OK.

⇶

orca-orchestration · session-handoff

stdin ←

Bloque orchestration: de .agents/project.yaml · el sprint, la ola o la sesión a continuar

stdout →

Flota: un conductor y workers persistentes (uno por historia o módulo) que hablan por el buzón del run; sin runtime, las mismas líneas de launch.txt se pegan a mano · Relevo: la sesión se compacta en .session/handoffs/ y una sucesora sigue en el mismo worktree y el mismo harness

nota

La flota es opcional: los subagentes de un turno siguen siendo el ejecutor por defecto.

✓

pr-review-lead

stdin ←

Un PR de test automation (este repo u otro, owner/repo#PR vía gh) · la doctrina KATA

stdout →

Review de QA Lead con cada hallazgo anclado a una cita de doctrina o a una ubicación de código · nunca publica en GitHub sin tu OK final

⎇

git-flow-master

dev + qa

stdout →

Branch {prefix}/{ISSUE-KEY}-{slug} · commit {type}({KEY}): {desc} · PR con body templado (Summary / Changes / Test Plan / Traceability / Risk)

Lista completa: este deck dibuja el flujo, no el inventario. Todas las skills, con su tier, modos y descripción, están en .agents/skills/REGISTRY.md (lo genera bun run skills:registry).

eof — deck hermano: naming-conventions (el Códice de Nomenclatura) define cómo se llama cada artefacto que este flujo produce.