Boilerplate · Playwright · KATA · Jira/Xray
Un repo instalable con un comando que trae el oficio entero: desde refinar los acceptance criteria antes del sprint hasta la decisión de release en CI. Cada stage lo ejecuta un skill, y la trazabilidad hacia Jira y Xray viene cableada de fábrica.
package.json y
.agents/project.yaml
bun install y bun setup, que abre una página
local con cada pregunta (--headless lo deja en la terminal)
gh si se lo pedís
Requisitos duros: Bun, Node, git y tar, más al menos uno de Claude Code, OpenCode o Codex.
01 · El pipeline
No son carpetas sueltas: es la secuencia del IQL. Cada stage recibe el artefacto del anterior y produce el que el siguiente necesita. Lo que empieza como un acceptance criterion ambiguo en el backlog termina siendo un test automatizado que vota en la decisión de release. Los stages se nombran con palabras, nunca con números.
→ deslizá el diagrama
/sprint-testing cubre tres stages seguidos, el resto uno cada uno, y
Observation está declarado sin skill (su unidad es una rutina agéntica). Abajo, lo que
cada stage deja escrito. Los dos saltos anchos son los handoffs con condición: una
Story sale del backlog cuando el shift-left la firma, y un test case cruza a
automatización solo con verdict Candidate.
Refina los acceptance criteria del backlog antes de que la Story entre al sprint: gaps, ambigüedades y el ATP escrito directo en el custom field de la Story, sin crear todavía ningún item en el TMS. El defecto se previene en el requisito.
QA manual por ticket, de punta a punta: planning con la familia ATS / ATP / ATR, ejecución explorando con la Trifuerza (UI · API · DB) y reporte final con los hallazgos clasificados y trazados a la Story.
Explora un módulo, un flujo o la app entera sin historia de por medio. Cada hallazgo pasa por alguien que intenta refutarlo, y cada escenario sale marcado contra la cobertura que ya existe, a la espera de que una persona confirme lo observado.
Corre el sprint con un worker de sprint-testing por ticket y te deja mirarlo todo desde el Sprint Board. El conductor no prueba: vigila el entorno de pruebas, lanza cuando un ticket llega de verdad, verifica cada cierre y retoma la flota después de un reinicio. Requiere Orca.
Documenta los test cases en el TMS y les da un veredicto de ROI: qué se automatiza, qué queda manual y qué se difiere. El verdict Candidate es la única puerta hacia Automation.
Plan → Code → Review sobre KATA + Playwright + TypeScript. Cada test case Candidate se convierte en un ATC con su ID de trazabilidad y viaja en un Pull Request revisable.
Corre las suites por CI/CD, clasifica cada fallo (bug real, test frágil o entorno) y emite la decisión de release. Es el único stage que le contesta al equipo con un veredicto, no con un artefacto.
Producción le devuelve al backlog lo que aprendió. El stage existe en la metodología y está declarado vacío en el repo: su unidad de trabajo es una rutina agéntica, no un workflow skill.
Fases, stages, steps y la escalera de artefactos, explicados en la documentación del repo. Las skills de soporte (tooling, orquestación, handoff) están en el catálogo de decks.
02 · Trazabilidad
Cada altitud de planificación tiene su artefacto, y cada artefacto tiene dueño y momento. Lo que parece burocracia de acrónimos es el mecanismo que hace que un test corriendo en CI se pueda rastrear hasta el acceptance criterion que lo originó.
→ deslizá el diagrama
El release de arquitectura cuenta por qué el árbol PBI dejó de commitearse en git, cómo apareció el ATS y cómo se verificó el modelo de coverage en vivo contra una instancia real de Xray. Leer el release de arquitectura →
Si lo que buscás es cómo se organiza la gestión de pruebas completa — la escalera MTP / FTP / STP / ATP, los cuatro epics de proceso en Jira, quién produce cada artefacto y cómo bajan al caché local — está todo en Test Management Architecture →
03 · Compatibilidad
El repo corre igual en Claude Code, OpenCode y Codex, en CLI y en Desktop. No hay tres copias de las instrucciones ni tres carpetas de skills: hay una sola fuente y adaptadores finos donde los hosts realmente difieren.
→ deslizá el diagrama
AGENTS.md nativo, Claude Code lo alcanza por un shim de una línea. Todo
lo generado se verifica en el pre-push.
AGENTS.md es la única entrada: carga siempre y su router nombra las
secciones de .agents/instructions/ que se leen a pedido.
CLAUDE.md es un shim generado que solo lo importa: prosa operativa ahí
adentro es drift y falla el check.
.agents/skills/. Claude Code las alcanza por
un alias generado y gitignoreado, nunca por una copia.
.mcp.json existen en las tres configs y se comparan
normalizadas: agregar un server en un solo host es un fallo, no un olvido.
04 · Cómo funciona
Cada deck explica una skill de punta a punta: cuándo se usa, qué lee, qué escribe y dónde frena para que decidas. Están agrupados por el momento del trabajo en que te hacen falta.
Los stages del pipeline
El backlog refinado antes del sprint: gaps, el ATP en el campo de la Story y la Story lista para estimar.
Planning · Execution · ReportingQA manual por ticket: plan, exploración con la Trifuerza y reporte trazado.
Execution sin ticketCharter, reconocimiento en paralelo, refutación y escenarios marcados contra la cobertura.
Sprint en flotaUna flota de workers por ticket, mirada desde el Sprint Board.
DocumentationTest cases en el TMS y un veredicto de ROI por escenario.
AutomationPlan, código y revisión sobre KATA + Playwright, solo para los Candidate.
RegressionSuites por CI, cada fallo clasificado y el veredicto de release.
Preparar un proyecto
Del repo desconocido al proyecto testeable: fases, mapas de dominio e
infraestructura y el handoff a project-context.
Cómo la IA genera y actualiza los mapas de datos, API y E2E y el Master Test Plan, sección por sección y con tu aprobación, y cruza los mapas con los tests para ver qué no está cubierto.
Categoría
Por qué existen las <aspect>-context, cómo se arma su mapa,
quién lo genera y cómo un proyecto crea las suyas.
Conecta el boilerplate a tu proyecto: análisis y plan sin escribir, tu aprobación, y recién ahí auth, entidad, CI y MCPs.
JiraComponents alineados con la app real y migración de sitio de Atlassian, cada cambio leído, mostrado y aprobado antes de escribirse.
Revisar y entregar
Ramas, commits, push y PRs adaptados a la estrategia declarada en
git_strategy:, con trailers forenses, paridad de rulesets, PRs
encadenados y worktrees.
Revisión de QA Lead sobre un PR de automatización: rigor elegido, cada hallazgo con su cita, nota calibrada y nada publicado sin tu OK.
Revisión adversarialDos jueces ciegos revisan el mismo cambio en paralelo; lo que confirman los dos se arregla y se vuelve a juzgar hasta APPROVED o ESCALATED.
EvidenciaConvierte una captura cruda en evidencia anotada (óvalo, flecha, recuadro, etiqueta BUG) renderizada en local, lista para el bug de Jira.
Herramientas y sesiones
Cómo las skills llegan a Jira, Xray, el navegador y la web: etiquetas, skills de
utilidad (acli, xray-cli), skills de comunidad y
capacidades MCP.
Cómo cargan las instrucciones del agente: AGENTS.md siempre, cada
sección de .agents/instructions/ cuando el router o una línea
ROUTE: la nombra.
Un conductor coordinando una flota de sesiones worker: una por historia, por módulo o por cluster de fallos. Opcional: sin runtime, las líneas de lanzamiento las pega una persona.
Sesiones largasCuando la ventana de contexto se llena, la sesión se compacta en un archivo y una sesión nueva sigue exactamente donde quedó.
Para mantenedores
Cómo se cambia el boilerplate mismo: plan aprobado, código por lotes, verificaciones en paralelo y la doc en el mismo PR.
Updaterbun sync
Qué sincroniza el updater, qué archivos del proyecto protege, por qué responde
todo antes de escribir y cómo leer el reporte con que cierra: la tabla por
superficie y el prompt de paridad, en la página local o en la terminal con
--headless.
Qué hace bun sync la primera vez sobre un repo con el layout viejo:
la migración corre al inicio de la misma corrida y se ve en la página o en la
terminal.
El sitio de documentación del repo: empezar, la metodología IQL, los fundamentos agénticos, el setup de Jira, Xray, DBHub y OpenAPI, y las variables de entorno.
05 · Academia
Los decks que explican el porqué detrás de cada stage: cómo se nombra, cómo se explora, cómo se clasifica un defecto y cómo habla el agente.
Cómo se nombra todo en el pipeline: artefactos, tests, ramas, IDs.
TransversalQué lee y qué produce cada skill, con una pestaña por fase.
TransversalEl contrato de voz del agente: qué dice, con cuánto detalle y en qué registro.
Shift-LeftPrevenir, no detectar: los defectos que mueren en los requisitos.
ExecutionLo que se ve, lo que viaja y lo que queda, probados por separado.
Execution · ReportingBug vs Defect vs Improvement, severidad, prioridad y traza a la Story.
DocumentationDel hallazgo suelto al test case que otro pueda ejecutar sin preguntarte.
Regression · mini-curso, parte ITriggers, jobs, secrets y artifacts sobre nuestros workflows reales.
Regression · mini-curso, parte IILa estrategia smoke / sanity / regression, el write-back al TMS y el gate a producción.
06 · Currículum
Ruta pedagógica secuencial para testers que arrancan sin código. Se sigue en orden: fundamentos → Playwright → arquitectura KATA.
07 · CI/CD en vivo
Último reporte publicado en este sitio por el workflow de regresión. Un proyecto con el portal privado de reportes lo publica allí, no acá.
Ver reporte →