Agentic QA Boilerplate
The QA workflow, but AI runs it. Playwright + KATA + TypeScript, con un principio simple: AI works, human decides.
bunx create-agentic-qa@latest mi-proyecto-qaUn comando: descarga el template, limpia el historial git, renombra el proyecto, corre bun install y lanza el instalador (bun setup), que abre una página local en tu navegador (con --headless se queda en la terminal) para configurar memoria Engram, skills, MCPs y .env.
Tú decides, el agente opera
El boilerplate convierte a tu asistente de IA en un QA que trabaja sobre tu stack real. Tú pones el criterio; él pone las manos.
Tú
Escribes el ticket y tomas las decisiones
El agente
Ejecuta el ciclo QA completo con skills
Tu stack
- Checkpoints humanos: el agente frena y espera tu OK antes de cada decisión que importa.
- Opera Jira, Xray y GitHub de verdad: comenta, transiciona tickets y abre PRs, sin que copies nada a mano.
- Memoria entre sesiones con Engram: lo que decidiste hoy sigue vigente mañana.
Una corrida de /sprint-testing
Un ticket trabajado de punta a punta: plan de testing, tu OK, ejecución trifuerza (UI + API + DB), reporte y transición en Jira.
claude — mi-proyecto-qa
/sprint-testing SCRUM-123
Leo la story: "Descuento por código promocional en checkout". 3 criterios de aceptación, 2 flujos de borde. Armo el plan de testing (ATP).
bun run jira:sync-issues(get SCRUM-123)
ATP listo: 8 test cases (3 happy path, 5 de borde)
esperando tu OKdale, súbelo y ejecuta
acli jira workitem create(ATP: SCRUM-123 · ítem Test Plan bajo el epic QA Master Test Plan)
Ejecuto con exploración trifuerza sobre staging: UI, API y base de datos.
playwright-cli(-s=SCRUM-123 open staging · flujo de descuento en checkout)
curl(POST /api/checkout · code=PROMO20 · 200 OK)
dbhub query(SELECT total, discount FROM orders ORDER BY created_at DESC)
8/8 test cases ejecutados · 1 observación menor · evidencia adjunta
Reporte de testing (ATR) redactado con evidencia y veredicto sugerido: aprobar.
Veredicto final de la story
esperando tu OKaprobada
acli jira workitem transition(SCRUM-123 → QA Approved)
SCRUM-123 en QA Approved · ATR publicado como comentario QA
Del backlog a la regresión, con checkpoints humanos
El pipeline cubre desde el shift-left pre-sprint hasta la regresión en CI/CD. Los pasos rosas son tuyos: ahí el agente frena y espera.
Onboarding
/project-discovery
Shift-Left
QA pre-sprint
Estimación
PO + Dev
Planning
ATP
OK al plan
decides tú
Execution
trifuerza
Reporting
ATR
Veredicto
decides tú
Documentation
TMS
Automation
KATA
PR review
decides tú
Regression
CI/CD
El agente toca Jira y GitHub de verdad
Workflow completo en Jira: Backlog → Shift-Left QA → Estimation → Ready For Dev → In Progress → In Review → Ready For QA → In Test → QA Approved. Y del lado de GitHub, la suite KATA entra por PR con checks verdes.
upex.atlassian.net/jira/software/projects/SCRUM/boards/1
Proyecto SCRUM
Sprint 14 · activoIn Progress
1Refactor del carrito
Ready For QA
1Login social con Google
In Test
1Descuento por código promocional
QA Approved
2Búsqueda por categoría
Checkout como invitado
github.com/tu-org/tu-proyecto/pull/87
test(checkout): KATA suite for discount flow #87
quiere mergear test/SCRUM-123-discount-flow en main
claude · pr-review-lead aprobó estos cambios
Suite alineada al ATP: 8 ATCs, selectores estables, retries: 0. Listo para merge.
Todos los checks pasaron
- TestBuild ChecksSuccessful
- typesSuccessful
- lintSuccessful
KATA: Komponent Action Test Architecture
Komponent Action Test Architecture es el nombre; las capas son otras. Los tests orquestan, los fixtures inyectan, los componentes de dominio implementan y la base habla con el mundo.
Consumen, no son capa
Test files
Orquestan ATCs en escenarios. No implementan ninguna capa.
Fixtures
Punto de inyección de dependencias hacia el archivo de test.
*Fixture.tsSteps
Cadenas de precondición reutilizables. No llevan @atc. (opcional)
loginAndSeedCart.step.tsComponentes de dominio
Acá, y solo acá, viven los métodos con el decorador @atc.
UsersApi, LoginPageBase
Helpers HTTP y helpers de Playwright.
ApiBase.ts · UiBase.tsTestContext
Drivers de Playwright, config, env y DataFactory. Agnóstico de API y de UI.
TestContext.tsTransversal a todas las capas
Utilities
decoradores @atc y @step
Test data
factories, tipos y constantes
Variables
entorno y URLs por proyecto
la capa superior usa la inferior, nunca al revés · retries: 0
Quieres ir a fondo en la arquitectura? Explorar KATA Academy
Todo incluido, nada que armar
El scaffolder deja el sistema entero listo: skills, MCPs, integración con el TMS, reportes y memoria persistente.
Skills por etapa
El ciclo QA entero (shift-left, sprint, docs, automation, regresión) más git, review adversarial, onboarding y CLIs de Atlassian. El catálogo vive en .agents/skills/REGISTRY.md.
Modos de skill
Una skill, varios modos que eliges por nombre: /project-context arma los business maps (data, e2e, api) y el plan maestro, que se escribe en el epic QA Master Test Plan de Jira.
MCPs preconfigurados
Los que declara .mcp.json: context7, slack-aurora, dbhub y openapi. El navegador va por playwright-cli, no por MCP.
Xray / Jira nativo
Test cases, ATPs, ATRs y ejecuciones sincronizados con el TMS desde el repo.
Allure 3
Reportes de ejecución publicados por CI/CD en cada suite de regresión.
Memoria Engram
El agente guarda decisiones, bugs y convenciones que sobreviven entre sesiones.
El oficio, explicado
No son cursos: son decks explicativos por skill, directo del maestro. Abre cualquiera y mira el skill en acción.
Test Automation (KATA)
Planifica, escribe y revisa tests automatizados KATA sobre Playwright + TypeScript — Plan → Code → Review, nunca directo al código.
Ver cómo funcionaTest Documentation & ROI
El puente entre QA manual y automatización: analiza, prioriza con ROI y documenta test cases en el TMS con trazabilidad completa.
Ver cómo funcionaSprint Testing
QA manual por ticket dentro del sprint: Planning → Execution → Reporting, con gates humanos en cada checkpoint.
Ver cómo funcionaShift-Left Testing
QA pre-sprint sobre un lote de Stories: refina Acceptance Criteria, saca a la luz gaps y ambigüedades, y deja el ATP redactado en el campo de la Story, en madurez outline.
Ver cómo funcionaRegression Testing & GO/NO-GO
Ejecuta la suite en CI, clasifica cada fallo con evidencia y convierte el resultado en un veredicto de release: GO / CAUTION / NO-GO.
Ver cómo funcionaTooling
Cómo una skill llega a Jira, a Xray, al navegador o a la web sin conocer la sintaxis de ninguna herramienta: escribe una etiqueta, el repo la resuelve y la skill dueña de la herramienta pone el cómo.
Ver cómo funcionaOrca Orchestration
Una sesión conductora coordina una flota de sesiones worker persistentes: una por historia, por módulo o por grupo de fallos.
Ver cómo funcionaFlujo E2E de los skills
Cómo viaja una historia por los dos boilerplates, del refinamiento a la regresión: qué recibe y qué entrega cada skill.
Ver cómo funcionaAgentic QA Onboard
El recorrido de bienvenida del repo: explica en palabras simples cómo funciona el flujo de QA y qué skill te toca llamar en cada momento, para quien se siente perdido.
Ver cómo funcionaPR Review Lead
Revisa el PR de automatización de otra persona como lo haría un QA Lead: cada observación apunta a una línea del diff o de la doctrina KATA, y en GitHub no se publica nada sin tu visto bueno.
Ver cómo funcionaBug Screenshot Annotation
Marca una captura cruda como lo haría una persona de QA (óvalo, flecha, texto y etiqueta BUG) para que quien abre el ticket entienda el defecto de un vistazo.
Ver cómo funcionaGit Flow Master
El operador de Git del repo: ramas, commits, push, pull requests, conflictos y worktrees, adaptados a la estrategia de branching que el proyecto declaró en .agents/project.yaml.
Ver cómo funcionaJudgment Day
Dos jueces revisan el mismo cambio en paralelo y a ciegas; lo que señalan los dos se arregla y se vuelve a juzgar, hasta un veredicto final APPROVED o ESCALATED.
Ver cómo funcionaSession Handoff
Cuando la ventana de contexto se llena, compacta la sesión en un archivo para que una sesión nueva siga exactamente donde quedó, como si la ventana se hubiera estirado en vez de reiniciarse.
Ver cómo funcionaProgressive Disclosure
Las instrucciones del repo en capas: AGENTS.md es el núcleo que carga siempre, cada tema vive en su archivo y un router, reforzado por un hook, dice cuál leer y cuándo.
Ver cómo funcionaContext skills
La categoría de skills que cambian lo que el agente sabe sobre un aspecto del producto o del método, nunca lo que hace después: llegan sin que nadie las pida y se leen por partes.
Ver cómo funcionaProject Discovery
Convierte un código que QA todavía no conoce en un proyecto testeable: lee el repo objetivo, pregunta lo ambiguo y deja escritos el dominio y la infraestructura donde el resto de las skills los busca.
Ver cómo funcionaProject Context
Genera y actualiza los mapas de negocio (datos, API, E2E) y el Master Test Plan, sección por sección y siempre con tu aprobación antes de pisar algo que ya existe.
Ver cómo funcionaTest Framework Adaptation
Conecta el boilerplate a tu app: login real, la primera entidad, variables, CI y MCPs, para que el repo quede listo para escribir tests KATA contra el sistema que vas a testear.
Ver cómo funcionaFramework Development
Para quien mantiene el framework: un cambio a KATA, fixtures, cli/, scripts/ o api/schemas/ pasa por un plan que apruebas, luego código, cuatro verificaciones y la documentación al día en el mismo PR.
Ver cómo funcionaJira Administration
Alinea los Components de Jira con los módulos reales de la app o repunta el repo a un sitio nuevo de Atlassian; en ambos casos la IA lee primero y no escribe nada sin tu aprobación.
Ver cómo funcionaOutput Style
Cómo escribe la IA a partir de ahora: dos capas gobiernan cada respuesta del chat, una el contenido y otra el formato, mostradas con una sesión de QA en los dos estilos.
Ver cómo funcionaHaces dev además de QA?
Agentic Dev Boilerplate
El mismo sistema, para el lado dev. De PRD a staging deploy.
- Skills para el ciclo de desarrollo completo, con los mismos checkpoints humanos.
- La misma dupla Jira + GitHub, operada por el agente.
Pruébalo en tu próximo ticket
Un comando instala todo. Después, /project-discovery aprende tu proyecto y ya puedes trabajar tickets con QA agéntico.
bunx create-agentic-qa@latest mi-proyecto-qa
cd mi-proyecto-qa
/project-discovery
/sprint-testing SCRUM-123Cuando /project-discovery deja listos los mapas de contexto de tu proyecto (las context skills), /sprint-testing ya puede trabajar tickets de punta a punta.
El repo es público y MIT: úsalo, forkéalo, mejóralo.