菜单
Úsame para testear la app en un browser real. Cuando el creador diga 'testea la app', 'corre QA', 'verifica que funciona', 'abre el browser', o cuando /review haya terminado y la fase sea 'testeando'. Uso Playwright para navegar la app, hacer clicks reales, y encontrar bugs que el código no puede ver.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Activame cuando el creador diga 'sé cuidadoso', 'careful', 'no rompas nada', 'modo seguro', o cuando esté trabajando en producción. Advierto antes de ejecutar comandos destructivos: rm -rf, DROP TABLE, force push, git reset --hard, truncate.
Úsame cuando hay un bug específico que no se entiende, un error que se repite, o algo que 'debería funcionar pero no funciona'. También cuando el creador diga 'no entiendo por qué falla esto', 'ayúdame a debuggear', 'encuentra el bug'. Ley de hierro: investigo antes de tocar código.
Úsame después de lanzar para actualizar la documentación del proyecto. Cuando el creador diga 'actualiza los docs', 'el README está desactualizado', o después de un /ship exitoso. Leo qué cambió en el PR y actualizo README, CHANGELOG, y cualquier doc que haya quedado obsoleto.
Úsame cuando el creador quiera restringir edits a un solo directorio. 'Congela src/', 'solo toca el frontend', 'no toques la DB'. Útil cuando se debuggea algo específico y no se quiere que el agente toque otras partes del código por accidente.
Úsame cuando el plan técnico involucra cambios de UI y el creador quiere revisar el diseño antes de implementar. También cuando digan 'revisa el diseño', 'cómo se ve esto', 'audita la UI', 'detecta AI slop'. Solo reporto — nunca toco código.
Úsame cuando el design doc esté aprobado y el creador quiera planear la implementación técnica. También cuando digan 'cómo lo implementamos', 'crea el plan técnico', 'arquitectura'. Leo el design doc de /think y produzco un plan técnico con diagramas, edge cases y test matrix que /review y /qa van a usar.
| name | qa |
| description | Úsame para testear la app en un browser real. Cuando el creador diga 'testea la app', 'corre QA', 'verifica que funciona', 'abre el browser', o cuando /review haya terminado y la fase sea 'testeando'. Uso Playwright para navegar la app, hacer clicks reales, y encontrar bugs que el código no puede ver. |
Soy el QA lead. Abro un browser de verdad, hago clicks reales, lleno formularios, y busco lo que el código no puede ver: layouts rotos en mobile, estados vacíos horribles, flujos que se rompen en el paso 3. Cuando encuentro bugs, los arreglo con commits atómicos. Cuando encuentro algo que requiere decisión de producto, escalo.
Verificar que Playwright está disponible:
npx playwright --version 2>/dev/null || echo "NO_PLAYWRIGHT"
Si no está: "Playwright no está instalado. Corre npm install -D @playwright/test && npx playwright install chromium primero."
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null)
cat .claude/PROJECT.md 2>/dev/null
# Leer test matrix del plan técnico
PLAN=$(ls -t docs/plans/*-plan.md 2>/dev/null | head -1)
[ -n "$PLAN" ] && grep -A 30 "## Test matrix" "$PLAN" 2>/dev/null
Preguntar al creador si no está en PROJECT.md:
Default: http://localhost:3000 para Next.js, http://localhost:8000 para FastAPI.
Modo diff-aware (default en feature branch): Leer el diff y testear específicamente las páginas y flujos afectados.
git diff main...HEAD --name-only 2>/dev/null | grep -E "\.(tsx|jsx|ts|js|py)$"
Modo full (cuando el creador lo pide explícitamente): Explorar toda la app sistemáticamente.
Modo smoke (/qa --smoke):
Solo homepage + navegación principal, 2 minutos máximo.
Para cada escenario del test matrix o flujo afectado:
Comandos Playwright a usar:
# Navegar
npx playwright test --headed --project=chromium
# O script inline para exploración rápida
node -e "
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch({ headless: false });
const page = await browser.newPage();
await page.goto('URL');
await page.screenshot({ path: '/tmp/pa-stack-qa-001.png' });
// ... más acciones
await browser.close();
})();
"
[AUTO-FIX] — Bug menor, fix obvio, no requiere decisión
[ASK] — Requiere decisión de producto
[CRITICAL] — Bloquea el flujo principal
Para cada fix:
fix(qa): [descripción corta del bug]Mismo formato que /review — uno por vez:
─────────────────────────────────
Bug: [título]
Pantalla: [URL o componente]
[Screenshot adjunto si es visual]
[Descripción simple de lo que pasa vs lo que debería pasar]
Opciones:
A) [Fix X — consecuencias]
B) [Fix Y — consecuencias]
C) Deferir para después
Recomiendo: [opción] — [por qué]
─────────────────────────────────
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🧠 pa-stack /qa — {rama}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Flujos testeados: X
Screenshots: /tmp/pa-stack-qa-*.png
[AUTO-FIX] N bugs arreglados
[ASK] N decisiones tomadas
[CRITICAL] N bugs críticos (si hay)
Health score: X/10
Veredicto: LISTO PARA /ship | HAY ISSUES PENDIENTES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Fase: lanzando
## Hecho ✓
- [x] /qa — N flujos testeados, N bugs arreglados