qa-only

Descripción general de la skill qa-only

qa-only es una skill de QA de solo informe para casos en los que quieres probar una aplicación web, documentar errores y capturar evidencias sin aplicar ninguna corrección. La skill qa-only es ideal para revisores de QA, responsables de producto y agentes que necesitan un flujo limpio de reporte de bugs, en lugar de un ciclo de probar-corregir-verificar. Si tu objetivo es “encontrar problemas y redactarlos”, qa-only es la opción adecuada; si quieres cambios de código, usa /qa en su lugar.

Para qué sirve qa-only

Esta skill se centra en una salida de QA estructurada: puntuación de salud, capturas de pantalla, pasos para reproducir y un informe de bugs claro. Está pensada para solicitudes de “solo comprobar si hay errores” y “probar, pero no corregir”, así que reduce la ambigüedad cuando el usuario quiere evidencia, no implementación.

En qué se diferencia qa-only

El valor principal de la qa-only skill es la contención. Encauza al agente hacia comportamientos de reporte y evita trabajos de reparación accidentales, algo importante cuando el entregable es un artefacto de revisión, una nota de triage o un informe de traspaso. Eso hace que qa-only for Qa sea especialmente útil en entornos donde las acciones de corrección están fuera de alcance o son arriesgadas.

Cuándo encaja y cuándo no

Usa qa-only cuando necesites una pasada de QA sobre una aplicación existente, especialmente para descubrir bugs, detectar regresiones o elaborar una evaluación por escrito. No lo instales como asistente general de pruebas si necesitas ediciones de código, refactors o corrección iterativa de errores; la qa-only guide está pensada deliberadamente para informar primero, no para reparar primero.

Cómo usar la skill qa-only

Instala y verifica la skill

Usa el flujo de instalación basado en repo: npx skills add garrytan/gstack --skill qa-only. Después de la instalación, confirma que los archivos de la skill estén presentes y sean legibles en tu directorio de skills antes de depender de ella en trabajo de producción. La qa-only install solo es útil si tu agente realmente puede cargar el contexto de la skill durante las ejecuciones de QA.

Dale el prompt de inicio correcto

Un buen prompt de qa-only usage debe especificar la app, el objetivo de prueba, qué significa “solo reporte de bugs” y cuáles son los límites. Buenos ejemplos serían: “Ejecuta qa-only sobre el flujo de checkout en staging, reporta solo bugs visibles, incluye pasos de reproducción y notas de capturas, no sugieras correcciones.” Prompts débiles como “Haz QA de esta app” dejan demasiado margen para que el modelo adivine alcance y severidad.

Lee primero estos archivos

Empieza con SKILL.md y luego revisa SKILL.md.tmpl para entender cómo se arma el flujo generado. Como este repo no incluye rules/, resources/ ni scripts adicionales, los dos archivos de la skill son la verdadera fuente de verdad sobre comportamiento, disparadores y restricciones. Ese es el camino más rápido si quieres entender qa-only antes de adoptarlo.

Úsala en un flujo de QA práctico

Un buen flujo de qa-only guide es: definir el área a probar, capturar el comportamiento esperado, dejar que la skill haga una revisión focalizada y luego convertir la salida en una lista de bugs o una nota de QA. Si el primer resultado es demasiado amplio, acota el alcance a un solo recorrido de usuario, un solo dispositivo/navegador o una sola release candidate. La skill funciona mejor cuando la tarea está acotada y el formato del informe es explícito.

Preguntas frecuentes sobre la skill qa-only

¿qa-only es solo para aplicaciones de navegador?

En su mayoría, sí. qa-only está orientada a QA y reporte de bugs en aplicaciones web, así que encaja con flujos de interfaz, entornos de staging y recorridos de usuario que pueden observarse y documentarse. Es menos útil para validaciones solo de backend o para tareas en las que no exista comportamiento visible del producto.

¿En qué se diferencia de un prompt normal?

Un prompt normal puede pedir QA, pero la qa-only skill añade una postura de reporte consistente y un comportamiento más claro alrededor de “no corregir”. Eso reduce las idas y vueltas cuando el equipo necesita un informe limpio de incidencias, en lugar de un resultado mixto de análisis más implementación.

¿qa-only es fácil para principiantes?

Sí, si el usuario puede nombrar la app, el entorno y el objetivo. El error más común al empezar es no especificar bien el alcance; la qa-only guide funciona mejor cuando indicas qué probar, qué evidencia recopilar y qué no hacer. Sin eso, el informe puede quedar demasiado genérico para ser útil.

¿Cuándo no debería usar qa-only?

No uses qa-only si tu necesidad real es depurar, parchear o verificar una corrección de extremo a extremo. Tampoco encaja bien si necesitas configurar automatización de pruebas avanzada, trabajo de infraestructura o cualquier cosa que dependa de acceso de escritura para cambiar código.

Cómo mejorar la skill qa-only

Define mejor el alcance y señales de aceptación más claras

La mejor forma de mejorar la salida de qa-only es definir un objetivo claro y una condición de éxito clara. Por ejemplo: “Prueba el formulario de inicio de sesión en Safari móvil, reporta validaciones rotas, incluye pasos, esperado vs. real y referencias a capturas.” Eso le da a la skill un marco medible en lugar de una solicitud de auditoría vaga.

Añade la evidencia que debe incluir el informe

Si quieres un informe de qa-only más útil, pide artefactos concretos: pasos de reproducción, URL o ruta afectada, severidad, frecuencia y si el problema bloquea, es cosmético o intermitente. Esto es mejor que pedir solo “encuentra bugs”, porque obliga a generar hallazgos estructurados que otra persona pueda usar rápido.

Vigila los fallos más comunes

El fallo más habitual es un alcance demasiado amplio: el agente intenta probarlo todo y el informe queda superficial. Otro fallo es mezclar intención de corrección en una tarea de solo reporte, lo que debilita el propósito de qa-only. Si eso ocurre, reformula la petición como “solo reporte, sin correcciones, sin cambios de código” y reduce la superficie de prueba.

Itera del primer informe al segundo pase

Usa el primer pase para descubrir los problemas más probables y luego ejecuta un segundo pase de qa-only sobre las rutas de bugs más importantes. Esto es especialmente útil cuando el primer informe revela un flujo crítico, pero quieres confirmar mejor casos límite, diferencias entre navegadores o la fiabilidad de la reproducción. La iteración es lo que convierte qa-only en un hábito de QA confiable, en lugar de un prompt puntual.