Agentic QA · Skill de orientación

/agentic-qa-onboard

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.

Guía, no ejecuta Habla como persona, no como terminal Abre un deck solo si decís que sí
Deck de la skill agentic-qa-onboard. Es la puerta de entrada: la primera vez que alguien abre el repo, o cuando no entiende cómo funciona una skill. Su trabajo termina en un handoff, nunca en el trabajo de QA en sí. Pulsá → para avanzar, S para modo presentador, O para overview, F para pantalla completa.

Cuándo usarla · 2 de 14

Para orientarte, no para trabajar

Lo que te pasaCon 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)
Las tres primeras filas son triggers de la description del SKILL.md (orientación, "I don't know how to use this", "how do I set this repo up for my app"). El resto es su lista "Do NOT use for" y la sección "What this skill does NOT do". El onboard nunca hace el trabajo de esas skills: te lleva hasta ellas.

Mapa · 3 de 14

De una duda a la skill que te toca

ENTRADA Llegás con una duda primera vez o perdido OBJETIVO CLARO? Si no: una sola pregunta un ticket o todo el flujo? TOUR DEL REPO Stack, pipeline, MCPs, variables lo justo para tu pregunta MODO ENSEÑANZA Concepto en palabras simples y te ofrece un deck, preguntando PROYECTO NUEVO Camino ordenado, fase 1 a 4 de un clon a tu app adaptada VARIAS SESIONES Los dos ejecutores, explicados sin lanzar ninguno HANDOFF Te pasa a la skill que toca y se hace a un lado /shift-left-testing · /sprint-testing /project-discovery · /test-framework-adaptation /orca-orchestration · ... la que corresponda a lo que querés hacer El tour termina cuando sabés qué skill llamar. Un deck por vez, siempre con tu OK.
Los cuatro caminos salen del SKILL.md: el tour (Welcome, Stack, Primary pipeline, MCPs, Env vars), "Teaching mode", "New project path" y "Running several sessions at once". La pregunta única cuando el objetivo no está claro es una Compact Rule y la regla 3 del modo enseñanza. El cierre es la última línea de la skill: el tour termina cuando el usuario sabe qué skill llamar.

Modo enseñanza · 4 de 14

Si estás perdido, cambia de voz

Las reglas, en orden

  1. Habla como una persona. Suspende el registro de trabajo escueto durante toda la explicación: frases completas, tono cálido, cada término técnico definido la primera vez.
  2. Te responde en tu idioma. Los decks están solo en español; si escribís en inglés, te lo avisa antes.
  3. Arranca donde estás. Si no está claro qué buscás, hace una sola pregunta.
  4. Concepto primero. Qué es y por qué importa, antes de cualquier comando, flag o ruta.
  5. Después ofrece el deck de la skill, con el protocolo de apertura.
  6. Handoff cuando ya sabés qué skill llamar.

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.

Fuente: sección "Teaching mode" del SKILL.md (las seis reglas, el ejemplo del ATC) y sus Compact Rules. .agents/instructions/agent-context-map.md dice lo mismo en la fila de orientación: el onboard entra en modo enseñanza, suspende el registro escueto y ofrece el deck de la skill, preguntando primero.

Decks · 5 de 14

Un deck por vez, y solo con tu OK

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).

Fuente: "Opening protocol (ALWAYS ask first)", "Published site (PREFERRED source)", "Cross-cutting reference decks", "CI mini-course" y "The docs site" del SKILL.md. Después de abrir uno, espera a que vuelvas con preguntas antes de ofrecer el siguiente. La lista de decks de la skill no se copia acá: el catálogo vive en la home publicada.

El tour · 6 de 14

Un boilerplate de QA con stack fijo

CapaElección
FrameworkPlaywright (E2E + API)
ArquitecturaKATA (TestContext / Base / Domain / Fixture)
ReportesAllure
TMSJira + Xray Cloud
LenguajeTypeScript (strict)
Runtimebun
Lint y formatoESLint + Prettier (pre-commit)
Agente de IAlos 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.

Fuente: secciones "Welcome", "Stack" y "First-time setup" del SKILL.md, más su Compact Rule de no sugerir otro stack. El detalle de lo que instala setup está en INSTALLER.md.

Proyecto nuevo · 7 de 14

bun setup es la fase 1, no todo

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>.

Fuente: "New project path" del SKILL.md. El detalle de la fase 3 sale del canon de la skill de adaptación (references/adaptation-workflow.md, Phase 0.2 Hard prerequisites), que lista lo que exige y qué comando lo produce. La oferta de Strategy Setup cuando la estrategia fue heredada del template está en git-flow-master/SKILL.md. Te sumás a un proyecto ya adaptado? Saltás las fases 2 a 4 y usás el checklist del slide 12.

El tour · 8 de 14

Un stage, una skill

StageSkillCuándoQué pasa
Shift-Left/shift-left-testingAntes del sprint, en loteRefina ACs de Stories del backlog, marca huecos y escribe temprano el ATP de cada Story
Planning, Execution, Reporting/sprint-testingEn el sprint, por ticketPlanning, Execution y Reporting: smoke más exploración UI / API / DB
Documentation/test-documentationDespués del QADocumenta casos en el TMS y los prioriza por ROI (Candidate / Manual / Deferred)
Automation/test-automationDespués del sprintTests E2E y de API sobre KATA y Playwright: Plan, Code, Review
Regression/regression-testingAntes del releaseCorre las suites en CI, clasifica fallas y da el veredicto GO / CAUTION / NO-GO
ObservationningunaEn producciónDeclarado 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.

Fuente: "Primary pipeline" del SKILL.md y su Compact Rule de no recitar estados de Jira de memoria. Los stages se nombran, nunca se numeran. /sprint-testing orquesta Planning, Execution y Reporting; de Documentation en adelante son handoffs explícitos. /sprint-testing saltea su propio refinamiento solo cuando el ATP publicado de la Story respalda un Shift-Left dentro de la ventana de frescura: la etiqueta sola no alcanza.

El tour · 9 de 14

Qué se crea y dónde se cuelga

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

  • FTP por feature o Epic (/sprint-testing)
  • STP al abrir el sprint y STR al cerrarlo (/sprint-testing; /regression-testing completa)
  • RTP de regresión, de larga vida (lo alimenta /test-documentation), con un RTR por corrida (/regression-testing)
  • MTP, el Master Test Plan (project-context, modo test-plan)

Tres ejes para cada bug

Parentun epic de proceso QA, por ejemplo "QA Defect Management"; nunca un epic de producto
Linkla Story de origen
Componentsel 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.

Fuente: los párrafos de artefactos y convenciones dentro de "Primary pipeline" del SKILL.md. El detalle de cada artefacto y su ciclo de vida está en agentic-qa-core/references/artifact-lifecycle.md y en defect-management-doctrine.md; el onboard solo los presenta.

Varias sesiones · 10 de 14

Dos ejecutores, uno opcional

Subagente de un solo usoWorker supervisado
Vivedentro del turno actual; su memoria muere con el reportecomo sesión persistente, con su propio alcance
Sirve paraleer, verificar o mapear algo; casi todo el trabajolo que no entra en un turno: una historia entera, un módulo automatizado e integrado
Estadoel defaultopcional, 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.

Fuente: "Running several sessions at once (optional)" del SKILL.md y su Compact Rule sobre los dos ejecutores. El onboard explica y hace el handoff; nunca lanza una flota. Deck de la skill: ../orca-orchestration/how-it-works.es.html.

El tour · 11 de 14

Qué herramienta para qué, y de dónde salen las credenciales

ParaUsá
"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 ticketbun 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.

Fuente: "MCPs available" y "Env vars, by scope" del SKILL.md. Las herramientas se resuelven por capacidad (por el sufijo del nombre de la tool), así que un conector de claude.ai o un servidor de nivel usuario cuentan igual; una capacidad que nadie provee es un STOP en el punto de uso. Qué servidores declara el proyecto: .mcp.json. Guía humana de variables: docs/core/variables-de-entorno.html.

Te sumás a un proyecto ya adaptado · 12 de 14

Antes de tu primer ticket

  • bun setup corrido
  • .env con lo que tu trabajo necesita, y web search conectado a nivel harness
  • Sesión del agente reiniciada después de completar .env
  • .agents/project.yaml poblado (bun run agents:setup)
  • bun run vars:check sin errores
  • bun run jira:check en verde
  • Navegadores de Playwright instalados (los baja bun setup; bun run pw:install si ese paso se saltó)
  • bun run context:hydrate armó la caché de Jira en .context/PBI/
  • El bloque git_strategy: dice strategy_source: chosen
  • La memoria de Engram responde (mem_context después de reiniciar)
  • Listo: /sprint-testing <KEY>

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.

Fuente: "Next steps after the onboard" del SKILL.md. La caché de .context/PBI/ está gitignoreada y se regenera: Jira sigue siendo la fuente de verdad. Si git_strategy todavía dice inherited, git-flow-master ofrece Strategy Setup en tu primera acción de git.

Salvaguardas · 13 de 14

Lo que la skill nunca hace

ReglaPor qué
Hacer ella misma el trabajo de otra skilles una guía; refinar, testear, documentar, automatizar o correr regresión tienen su dueña
Abrir un deck sin preguntar, o varios de golpeabre tu navegador: es una acción hacia afuera, y uno por vez se puede digerir
Recitar un estado de Jira de memoriasi no está en .agents/jira-workflows.json, no existe en tu instancia
Sugerir cambiar el stackPlaywright, KATA, Allure, TypeScript y bun están fijos; KATA depende de Playwright
Volcarte el pipeline entero si preguntaste por una partearranca donde estás; ante la duda, una sola pregunta
Darte un comando antes del conceptoprimero qué es y por qué importa; después la ruta o el flag
Lanzar o supervisar una flota de sesionessolo explica que la opción existe; eso es /orca-orchestration
Darte solo el checklist en un proyecto nuevocubre la fase 1; un proyecto nuevo recorre las fases 1 a 4 en orden
Fuente: Compact Rules del SKILL.md, "Opening protocol", "What this skill does NOT do" y la description ("this skill only explains that the option exists").

Cierre · 14 de 14

Invocación y dónde leer más

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

Fin del recorrido. El mapa del slide 3 lo resume: una duda entra, como mucho una pregunta para ubicarte, el camino que te toca, explicado en palabras simples, y un handoff. La skill no tiene "## Mode routing": se invoca por nombre.
← → navegar · O resumen · S presentador · N notas · F pantalla