Agentic QA · Skill de orientación
El recorrido de bienvenida del repo y el mostrador de ayuda para quien se siente perdido. Te explica en palabras simples cómo funciona el flujo de QA y qué skill te toca llamar; cuando ya lo sabés, se hace a un lado.
Cuándo usarla · 2 de 14
| Lo que te pasa | Con qué |
|---|---|
| "Acabo de clonar el repo, por dónde empiezo?" | /agentic-qa-onboard |
| "No sé cómo usar esto" · "cómo funciona /sprint-testing?" | /agentic-qa-onboard, modo enseñanza |
| "Cómo configuro el repo para mi proyecto?" | /agentic-qa-onboard, camino de proyecto nuevo |
| Refinar Stories del backlog antes del sprint | /shift-left-testing |
| Testear un ticket | /sprint-testing |
| Documentar casos de prueba en el TMS | /test-documentation |
| Escribir tests automatizados | /test-automation |
| Correr una suite de regresión | /regression-testing |
| Lanzar o supervisar varias sesiones en paralelo | /orca-orchestration (el onboard solo te cuenta que existe) |
Mapa · 3 de 14
Modo enseñanza · 4 de 14
Las reglas, en orden
Un término, definido
"Un ATC: básicamente un caso de prueba completo, de punta a punta." Así suena una definición en el modo enseñanza.
Una excepción declarada
El registro comprimido es el default del repo. Esta skill lo deja en pausa a propósito, y vuelve a su estilo normal cuando ya te orientaste.
No te tira todo encima
Si preguntaste por un stage, no te recita el pipeline entero.
Decks · 5 de 14
1 · Pregunta
"Te abro el deck?"
abre tu navegador por defecto
2 · Idioma
Avisa que es en español
si le hablás en inglés
3 · Abre uno
URL publicada primero
copia local solo offline o si la pedís
4 · Acompaña
Te dice las teclas
← → para moverte, S para notas
Por qué la URL publicada
Los decks se publican en el sitio de GitHub Pages del boilerplate. Un proyecto creado desde el boilerplate puede no traer los HTML; la URL publicada funciona igual.
Además de los decks por skill
Decks transversales de agentic-qa-core (cómo se nombra todo; qué lee y qué produce cada skill), el mini curso de CI de regression-testing y la KATA Academy interactiva para preguntas de arquitectura. El catálogo completo está en la home publicada.
El sitio de docs
bun run docs y bun run onboarding levantan un servidor que bloquea. Mismo protocolo: pregunta, y te sugiere correrlo en tu propia terminal (! bun run docs).
El tour · 6 de 14
| Capa | Elección |
|---|---|
| Framework | Playwright (E2E + API) |
| Arquitectura | KATA (TestContext / Base / Domain / Fixture) |
| Reportes | Allure |
| TMS | Jira + Xray Cloud |
| Lenguaje | TypeScript (strict) |
| Runtime | bun |
| Lint y formato | ESLint + Prettier (pre-commit) |
| Agente de IA | los hosts de §4.5 (.agents/instructions/agent-harnesses.md) |
Solo QA
El repo trae skills, scripts y convenciones para llevar un ticket de Jira a casos documentados y cobertura automatizada. La app bajo prueba no vive acá: está en otro repo, configurado en .agents/project.yaml.
El stack no se cambia
KATA es específico de Playwright. Si tu proyecto necesita Cypress o Robot Framework, este boilerplate no es el punto de partida, y la skill no te va a sugerir cambiarlo.
Primer paso
bun setup, completar .env y reiniciar la sesión del agente: los MCP leen .env al arrancar. El chequeo de salud es bun run setup:doctor.
Proyecto nuevo · 7 de 14
Fase 1 · Base
Herramientas en verde
setup → .env → reinicio → setup:doctor
Fase 2 · Jira
Catálogos del tracker
jira:sync-fields · jira:sync-workflows · jira:sync-link-types → /jira-administration components
Fase 3 · Tu app
Discovery y adaptación
/project-discovery → /test-framework-adaptation
Fase 4 · Git
Estrategia elegida
"set up our git strategy" → git_strategy: en project.yaml
Fase 2 en detalle
Los scripts generan los catálogos .agents/*.json que leen todas las skills. Los Components de Jira se reconcilian con los módulos reales de tu app. Para provisionar Jira desde cero: docs/core/setup/jira-xray.html.
El orden se impone solo
/project-discovery genera los mapas de dominio e infraestructura y .context/project-config.md. /test-framework-adaptation no empieza sin ellos ni sin el mapa de datos (project-context, modo data), y te dice qué falta.
Fase 4 y después
Si la salteás, /git-flow-master te la ofrece en tu primera acción de git. bun run git:policy apply la refleja en GitHub (opcional). Al final: bun run context:hydrate y /sprint-testing <KEY>.
El tour · 8 de 14
| Stage | Skill | Cuándo | Qué pasa |
|---|---|---|---|
| Shift-Left | /shift-left-testing | Antes del sprint, en lote | Refina ACs de Stories del backlog, marca huecos y escribe temprano el ATP de cada Story |
| Planning, Execution, Reporting | /sprint-testing | En el sprint, por ticket | Planning, Execution y Reporting: smoke más exploración UI / API / DB |
| Documentation | /test-documentation | Después del QA | Documenta casos en el TMS y los prioriza por ROI (Candidate / Manual / Deferred) |
| Automation | /test-automation | Después del sprint | Tests E2E y de API sobre KATA y Playwright: Plan, Code, Review |
| Regression | /regression-testing | Antes del release | Corre las suites en CI, clasifica fallas y da el veredicto GO / CAUTION / NO-GO |
| Observation | ninguna | En producción | Declarado y vacío: todavía ninguna skill lo cubre |
Estados de Jira: nunca de memoria
La fuente es .agents/jira-workflows.json (se regenera con bun run jira:sync-workflows). Si un estado no está ahí, no existe en tu instancia. /shift-left-testing mueve los estados previos al sprint, /sprint-testing los de QA, y PO y dev el tramo del medio.
Qué ya está cubierto?
bun run tests:map dibuja el árbol Epic → Story → Test sincronizado en una página HTML, con huérfanos y un resumen por componente.
El tour · 9 de 14
Por cada Story
ATP el plan · ATR los resultados · ATS el Acceptance Test Set que agrupa todos sus casos; su link a la Story llena el panel de cobertura de Xray.
Por encima de la Story
Tres ejes para cada bug
| Parent | un epic de proceso QA, por ejemplo "QA Defect Management"; nunca un epic de producto |
| Link | la Story de origen |
| Components | el módulo de la app |
Components obligatorios
En bugs, defects, improvements y Tests. Se reconcilian con los módulos reales de la app con /jira-administration, modo components.
Varias sesiones · 10 de 14
| Subagente de un solo uso | Worker supervisado | |
|---|---|---|
| Vive | dentro del turno actual; su memoria muere con el reporte | como sesión persistente, con su propio alcance |
| Sirve para | leer, verificar o mapear algo; casi todo el trabajo | lo que no entra en un turno: una historia entera, un módulo automatizado e integrado |
| Estado | el default | opcional, vía /orca-orchestration |
Cómo se organiza
Una sesión conductora coordina una flota de workers, por rondas. Cada skill de flujo sigue mandando en el qué; la orquestación, en el cómo.
Es opcional
Necesita un runtime de orquestación instalado y alcanzable. Sin él, las skills ni lo mencionan: escriben su archivo de lanzamiento y vos pegás las líneas en tus terminales.
No es "QA más rápida"
En un sprint real, el valor fue ver el mismo entorno desde varios ángulos, incluso un worker que se negó a seguir una instrucción equivocada. Las cifras: ADR-0006.
El tour · 11 de 14
| Para | Usá |
|---|---|
| "Cómo se usa X?" (docs oficiales) | Context7, capacidad library-docs |
| "Cómo resuelvo X?" (comunidad, errores) | capacidad web-search, un servidor a nivel harness: Exa primero, Tavily después |
| Escribir en un ticket | /acli |
| Leer el detalle de un ticket | bun run jira:sync-issues get y el .md sincronizado |
| Cualquier cosa en el navegador | /playwright-cli (no hay MCP de navegador) |
.mcp.json sin secretos
Se commitea solo con nombres de variables: cada MCP arranca con el loader de .env delante y su --filter. .env es la única fuente y nadie hace copias. El MCP de Atlassian es opt-in.
Variables por alcance
Cada una tiene su alcance en cli/lib/variables-manifest.ts. Nada bloquea la instalación: el código que la lee falla con un error que la nombra. La lista es .env.example.
El host de Jira no va en .env
Vive en .agents/project.yaml; se lee con bun run --silent jira:url. Chequeos: bun run vars:env:check y bun run setup:doctor.
Te sumás a un proyecto ya adaptado · 12 de 14
Si una casilla queda vacía, eso se arregla primero: las skills de flujo dan por hecho que la base está en verde. En un proyecto nuevo este checklist no alcanza: cubre solo la fase 1 del camino del slide 7.
Salvaguardas · 13 de 14
| Regla | Por qué |
|---|---|
| Hacer ella misma el trabajo de otra skill | es una guía; refinar, testear, documentar, automatizar o correr regresión tienen su dueña |
| Abrir un deck sin preguntar, o varios de golpe | abre tu navegador: es una acción hacia afuera, y uno por vez se puede digerir |
| Recitar un estado de Jira de memoria | si no está en .agents/jira-workflows.json, no existe en tu instancia |
| Sugerir cambiar el stack | Playwright, KATA, Allure, TypeScript y bun están fijos; KATA depende de Playwright |
| Volcarte el pipeline entero si preguntaste por una parte | arranca donde estás; ante la duda, una sola pregunta |
| Darte un comando antes del concepto | primero qué es y por qué importa; después la ruta o el flag |
| Lanzar o supervisar una flota de sesiones | solo explica que la opción existe; eso es /orca-orchestration |
| Darte solo el checklist en un proyecto nuevo | cubre la fase 1; un proyecto nuevo recorre las fases 1 a 4 en orden |
Cierre · 14 de 14
Cómo se invoca
Claude Code: /agentic-qa-onboard.
OpenCode y Codex: cargá la skill agentic-qa-onboard.
No tiene modos. También la disparan frases como "onboard me", "no sé cómo usar esto", "cómo funciona este skill" o "setup completo del repo".
Qué lee
Su propio SKILL.md · para la lista de skills, §5 (.agents/instructions/agent-skills-and-mcps.md) y .agents/skills/REGISTRY.md · para estados de Jira, .agents/jira-workflows.json · para skills de la comunidad, cli/install.ts.
Qué deja
Nada escrito en el repo. Una explicación a tu medida, como mucho un deck abierto con tu OK, y el nombre de la skill que tenés que llamar.
Canon
.agents/skills/agentic-qa-onboard/SKILL.md (tour, modo enseñanza, protocolo de decks, camino de proyecto nuevo, checklist). Las skills de flujo son dueñas de su propio detalle: el onboard las presenta, no las reescribe.
Siguientes decks: /shift-left-testing · /sprint-testing · /jira-administration · /project-discovery · /test-framework-adaptation · /git-flow-master · /orca-orchestration · entradas y salidas por skill