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.

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 (5 stages) │ ▼ FASE 4 · Testing qa-boilerplate ├─ 4a sprint-testing QA manual por ticket ├─ 4b test-documentation TMS + ROI ├─ 4c test-automation KATA · solo verdict Candidate └─ 4d regression-testing release gate GO / NO-GO

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``` · cache local stories/STORY-<KEY>-<slug>/spec.md

Enumeración de edge cases

dev

skills

product-management (references/edge-cases-enumeration.md)brainstorming (T4 · opcional)

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

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

Refinamiento (loop por historia)

skills

sprint-testing/references/acceptance-test-planning.md §1-3+4refinement-playbook.mdatp-draft-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.mdacli / xray-clidefect-management-doctrine.mdtraceability-linking.md

stdin ←

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

jira ⇄

Campos: {{jira.acceptance_criteria}} · {{jira.acceptance_test_plan}} (o Test Plan issue si Xray + opt-in) · {{jira.qa_assignee}} solo si está vacío · Labels: shift-left-reviewed + shift-left-{{YYYY-MM-DD}} · Transiciones: Backlog → Shift-Left QA → Estimation · Comentario: «ATP — Shift-Left DRAFT»

loop 2a ⇄ 2b hasta ACs firmes → exit 0 → status Ready For Dev

fase 3 · repo dev-boilerplate

Implementación sprint-development

Mega-orquestador de 5 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 · CLAUDE.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: Stages 1-3 — Planning · Execution · Reporting.

Planning

skills

test-design-doctrine.md — MANDATORIOdefect-management-doctrine.md — MANDATORIOacli / xray-clishift-left-testing (short-circuit si label <30 días)

stdin ←

story.md · acceptance-criteria.md · acceptance-test-plan.md · comments.md · domain-glossary.md · master-test-plan.md · campos {{jira.qa_assignee}} · AC · priority · label shift-left-reviewed

stdout →

Test Plan «ATP: {STORY}: {título}» → epic QA Master Test Plan · (Xray) Test issues + Test Execution · links Story↔ATP · 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 Stage 3 → test-automation, no en Planning.

Execution (trifuerza UI · API · DB)

skills

playwright-cli (UI)OpenAPI MCP + curl (API)DBHub MCP (DB)bug-screenshot-annotation (bugs visuales)

stdin ←

ATP de Stage 1 · 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 ⇄

Test Execution «ATR: {STORY}: Story Testing» → epic QA Test Artifacts · 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

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

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 ←

master-test-plan.md — línea TMS: Xray on Jira o TMS: Jira native · [ISSUE_TRACKER_TOOL] List issue types

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) · domain-glossary.md

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: description con template TC · labels · Test Status · links Story-ATP-ATR-TC · 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/StepsFixture · tests/e2e/{module}/{verbFeature}.test.ts

Review

skills

judgment-day (opcional)test-documentation + acli (transición del TC)

stdin ←

Archivos nuevos/modificados de Code

stdout →

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

jira ⇄

TC → In Review (al abrir PR) → Automated (al mergear a main 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 · CLAUDE.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. Gate opcional en: Stage 3 dev · Review de test-automation · 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 3 epics QA fijos

jira ⇄

QA Defect Management → bugs / defects / improvements · QA Master Test Plan → ATP / Test Plans · QA Test Artifacts → ATR / Test Executions · nunca un epic de producto — la Story origen viaja por issue-link, el módulo afectado por components (modelo de 3 ejes)

⎇

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)

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