Nota de referencia: Este repositorio es la capa de documentación en coreano del upstream
gstack. El contenido a continuación es una referencia basada en la instalación upstream; la ejecución real debe seguir el entorno upstream.
Preámbulo (ejecutar primero)
_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_PROACTIVE=$(~/.claude/skills/gstack/bin/gstack-config get proactive 2>/dev/null || echo "true")
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"
echo "PROACTIVE: $_PROACTIVE"
source <(~/.claude/skills/gstack/bin/gstack-repo-mode 2>/dev/null) || true
REPO_MODE=${REPO_MODE:-unknown}
echo "REPO_MODE: $REPO_MODE"
_LAKE_SEEN=$([ -f ~/.gstack/.completeness-intro-seen ] && echo "yes" || echo "no")
echo "LAKE_INTRO: $_LAKE_SEEN"
_TEL=$(~/.claude/skills/gstack/bin/gstack-config get telemetry 2>/dev/null || true)
_TEL_PROMPTED=$([ -f ~/.gstack/.telemetry-prompted ] && echo "yes" || echo "no")
_TEL_START=$(date +%s)
_SESSION_ID="$$-$(date +%s)"
echo "TELEMETRY: ${_TEL:-off}"
echo "TEL_PROMPTED: $_TEL_PROMPTED"
mkdir -p ~/.gstack/analytics
echo '{"skill":"qa","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","repo":"'$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown")'"}' >> ~/.gstack/analytics/skill-usage.jsonl 2>/dev/null || true
# zsh-compatible: usar find en lugar de glob para evitar errores NOMATCH
for _PF in $(find ~/.gstack/analytics -maxdepth 1 -name '.pending-*' 2>/dev/null); do [ -f "$_PF" ] && ~/.claude/skills/gstack/bin/gstack-telemetry-log --event-type skill_run --skill _pending_finalize --outcome unknown --session-id "$_SESSION_ID" 2>/dev/null || true; break; done
Si PROACTIVE es "false", no sugieras skills de gstack de forma proactiva; solo invócalos cuando el usuario lo pida explícitamente. El usuario ha optado por no recibir sugerencias proactivas.
Si la salida muestra UPGRADE_AVAILABLE <old> <new>: lee ~/.claude/skills/gstack/gstack-upgrade/SKILL.md y sigue el "Flujo de actualización en línea" (actualización automática si está configurada, de lo contrario usa AskUserQuestion con 4 opciones, escribe el estado de posposición si se rechaza). Si JUST_UPGRADED <from> <to>: dile al usuario "Ejecutando gstack v{to} (¡recién actualizado!)" y continúa.
Si LAKE_INTRO es no: Antes de continuar, presenta el Principio de Integridad. Dile al usuario: "gstack sigue el principio Hierve el lago — haz siempre la tarea completa cuando la IA hace que el costo marginal sea casi nulo. Más información: https://garryslist.org/posts/boil-the-ocean" Luego ofrécele abrir el ensayo en su navegador predeterminado:
open https://garryslist.org/posts/boil-the-ocean
touch ~/.gstack/.completeness-intro-seen
Solo ejecuta open si el usuario dice que sí. Siempre ejecuta touch para marcarlo como visto. Esto solo ocurre una vez.
Si TEL_PROMPTED es no Y LAKE_INTRO es yes: Después de manejar la introducción del lago, pregúntale al usuario sobre la telemetría. Usa AskUserQuestion:
¡Ayuda a que gstack mejore! El modo comunitario comparte datos de uso (qué skills usas, cuánto tiempo toman, información de errores) con un ID de dispositivo estable para que podamos rastrear tendencias y corregir errores más rápido. Nunca se envían códigos, rutas de archivos ni nombres de repositorios. Cámbialo en cualquier momento con
gstack-config set telemetry off.
Opciones:
- A) ¡Ayuda a que gstack mejore! (recomendado)
- B) No, gracias
Si elige A: ejecuta ~/.claude/skills/gstack/bin/gstack-config set telemetry community
Si elige B: haz una pregunta de seguimiento con AskUserQuestion:
¿Qué tal el modo anónimo? Solo nos enteramos de que alguien usó gstack — sin ID único, sin forma de conectar sesiones. Solo un contador que nos ayuda a saber si hay alguien ahí fuera.
Opciones:
- A) Claro, el anónimo está bien
- B) No, gracias, completamente desactivado
Si B→A: ejecuta ~/.claude/skills/gstack/bin/gstack-config set telemetry anonymous
Si B→B: ejecuta ~/.claude/skills/gstack/bin/gstack-config set telemetry off
Siempre ejecuta:
touch ~/.gstack/.telemetry-prompted
Esto solo ocurre una vez. Si TEL_PROMPTED es yes, omite todo esto.
Formato AskUserQuestion
SIEMPRE sigue esta estructura para cada llamada AskUserQuestion:
- Recontextualizar: Indica el proyecto, la rama actual (usa el valor de
_BRANCHimpreso por el preámbulo — NO ninguna rama del historial de la conversación o gitStatus) y el plan/tarea actual. (1-2 oraciones) - Simplificar: Explica el problema en inglés sencillo que un inteligente joven de 16 años pueda seguir. Sin nombres de funciones en bruto, sin jerga interna, sin detalles de implementación. Usa ejemplos concretos y analogías. Di lo que HACE, no cómo se llama.
- Recomendar:
RECOMENDACIÓN: Elige [X] porque [razón de una línea]— siempre prefiere la opción completa sobre los atajos (ver Principio de Integridad). IncluyeIntegridad: X/10para cada opción. Calibración: 10 = implementación completa (todos los casos extremos, cobertura total), 7 = cubre el camino feliz pero omite algunos bordes, 3 = atajo que aplaza trabajo significativo. Si ambas opciones son 8+, elige la más alta; si una es ≤5, márcala. - Opciones: Opciones con letras:
A) ... B) ... C) ...— cuando una opción implique esfuerzo, muestra ambas escalas:(humano: ~X / CC: ~Y)
Supón que el usuario no ha mirado esta ventana en 20 minutos y no tiene el código abierto. Si necesitaras leer el código fuente para entender tu propia explicación, es demasiado compleja.
Las instrucciones por skill pueden agregar reglas de formato adicionales además de esta línea base.
Principio de Integridad — Hierve el Lago
La IA hace que la integridad sea casi gratuita. Siempre recomienda la opción completa sobre los atajos — el delta es de minutos con CC+gstack. Un "lago" (cobertura del 100%, todos los casos extremos) es hervible; un "océano" (reescritura completa, migración de varios trimestres) no lo es. Hierve lagos, marca océanos.
Referencia de esfuerzo — siempre muestra ambas escalas:
| Tipo de tarea | Equipo humano | CC+gstack | Compresión |
|---|---|---|---|
| Código repetitivo | 2 días | 15 min | ~100x |
| Pruebas | 1 día | 15 min | ~50x |
| Funcionalidad | 1 semana | 30 min | ~30x |
| Corrección de errores | 4 horas | 15 min | ~20x |
Incluye Integridad: X/10 para cada opción (10=todos los casos extremos, 7=camino feliz, 3=atajo).
Propiedad del Repositorio — Ve Algo, Di Algo
REPO_MODE controla cómo manejar problemas fuera de tu rama:
solo— Eres dueño de todo. Investiga y ofrécete a corregir de forma proactiva.collaborative/unknown— Márcalo con AskUserQuestion, no lo corrijas (puede ser de otra persona).
Siempre marca cualquier cosa que parezca incorrecta — una oración, lo que notaste y su impacto.
Buscar Antes de Construir
Antes de construir cualquier cosa desconocida, busca primero. Consulta ~/.claude/skills/gstack/ETHOS.md.
- Capa 1 (probado y comprobado) — no reinventes. Capa 2 (nuevo y popular) — examina. Capa 3 (primeros principios) — valora por encima de todo.
Eureka: Cuando el razonamiento de primeros principios contradiga la sabiduría convencional, nómbralo y registra:
jq -n --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --arg skill "SKILL_NAME" --arg branch "$(git branch --show-current 2>/dev/null)" --arg insight "RESUMEN_EN_UNA_LÍNEA" '{ts:$ts,skill:$skill,branch:$branch,insight:$insight}' >> ~/.gstack/analytics/eureka.jsonl 2>/dev/null || true
Modo Colaborador
Si _CONTRIB es true: estás en modo colaborador. Al final de cada paso importante del flujo de trabajo, califica tu experiencia con gstack del 0 al 10. Si no es un 10 y hay un error o mejora procesable — presenta un informe de campo.
Presenta solo: Errores de las herramientas de gstack donde la entrada era razonable pero gstack falló. Omite: Errores de la aplicación del usuario, errores de red, fallos de autenticación en el sitio del usuario.
Para presentar: escribe ~/.gstack/contributor-logs/{slug}.md:
# {Título}
**Lo que intenté:** {acción} | **Lo que pasó:** {resultado} | **Calificación:** {0-10}
## Reproducción
1. {paso}
## Qué haría de esto un 10
{una oración}
**Fecha:** {YYYY-MM-DD} | **Versión:** {versión} | **Skill:** /{skill}
Slug: guiones en minúsculas, máximo 60 caracteres. Omite si existe. Máximo 3/sesión. Presenta en línea, no te detengas.
Protocolo de Estado de Finalización
Al completar un flujo de trabajo de skill, informa el estado usando uno de:
- HECHO — Todos los pasos completados con éxito. Se proporcionó evidencia para cada afirmación.
- HECHO_CON_PREOCUPACIONES — Completado, pero con problemas que el usuario debe conocer. Enumera cada preocupación.
- BLOQUEADO — No se puede continuar. Indica qué bloquea y qué se intentó.
- NECESITA_CONTEXTO — Falta información necesaria para continuar. Indica exactamente qué necesitas.
Escalada
Siempre está bien detenerse y decir "esto es demasiado difícil para mí" o "no confío en este resultado".
Un trabajo malo es peor que ningún trabajo. No serás penalizado por escalar.
- Si has intentado una tarea 3 veces sin éxito, DETENTE y escala.
- Si no estás seguro acerca de un cambio sensible a la seguridad, DETENTE y escala.
- Si el alcance del trabajo excede lo que puedes verificar, DETENTE y escala.
Formato de escalada:
ESTADO: BLOQUEADO | NECESITA_CONTEXTO
RAZÓN: [1-2 oraciones]
INTENTADO: [lo que intentaste]
RECOMENDACIÓN: [lo que el usuario debería hacer a continuación]
Telemetría (ejecutar al final)
Después de que el flujo de trabajo del skill se complete (éxito, error o cancelación), registra el evento de telemetría.
Determina el nombre del skill desde el campo name: en el frontmatter YAML de este archivo.
Determina el resultado del flujo de trabajo (éxito si se completó normalmente, error si falló, cancelación si el usuario interrumpió).
EXCEPCIÓN DEL MODO PLAN — EJECUTAR SIEMPRE: Este comando escribe telemetría en
~/.gstack/analytics/ (directorio de configuración del usuario, no archivos del proyecto). El preámbulo del skill ya escribe en el mismo directorio — este es el mismo patrón.
Omitir este comando pierde los datos de duración de la sesión y resultado.
Ejecuta este bash:
_TEL_END=$(date +%s)
_TEL_DUR=$(( _TEL_END - _TEL_START ))
rm -f ~/.gstack/analytics/.pending-"$_SESSION_ID" 2>/dev/null || true
~/.claude/skills/gstack/bin/gstack-telemetry-log \
--skill "NOMBRE_DEL_SKILL" --duration "$_TEL_DUR" --outcome "RESULTADO" \
--used-browse "USÓ_BROWSE" --session-id "$_SESSION_ID" 2>/dev/null &
Reemplaza NOMBRE_DEL_SKILL con el nombre real del skill desde el frontmatter, RESULTADO con
success/error/abort, y USÓ_BROWSE con true/false según si se usó $B.
Si no puedes determinar el resultado, usa "unknown". Esto se ejecuta en segundo plano y
nunca bloquea al usuario.
Pie de página de Estado del Plan
Cuando estés en modo plan y estés a punto de llamar a ExitPlanMode:
- Verifica si el archivo del plan ya tiene una sección
## INFORME DE REVISIÓN DE GSTACK. - Si la TIENE — omite (un skill de revisión ya escribió un informe más completo).
- Si NO la tiene — ejecuta este comando:
```bash ~/.claude/skills/gstack/bin/gstack-review-read ```
Luego escribe una sección ## INFORME DE REVISIÓN DE GSTACK al final del archivo del plan:
- Si la salida contiene entradas de revisión (líneas JSONL antes de
---CONFIG---): formatea la tabla de informe estándar con ejecuciones/estado/hallazgos por skill, con el mismo formato que usan los skills de revisión. - Si la salida es
NO_REVIEWSo está vacía: escribe esta tabla de marcador de posición:
```markdown
INFORME DE REVISIÓN DE GSTACK
| Revisión | Disparador | Por qué | Ejecuciones | Estado | Hallazgos |
|---|---|---|---|---|---|
| Revisión CEO | `/plan-ceo-review` | Alcance y estrategia | 0 | — | — |
| Revisión Codex | `/codex review` | Segunda opinión independiente | 0 | — | — |
| Revisión Ing. | `/plan-eng-review` | Arquitectura y pruebas (obligatorio) | 0 | — | — |
| Revisión Diseño | `/plan-design-review` | Brechas de UI/UX | 0 | — | — |
VEREDICTO: AÚN NO HAY REVISIONES — ejecuta `/autoplan` para el pipeline completo de revisión, o revisiones individuales arriba. ```
EXCEPCIÓN DEL MODO PLAN — EJECUTAR SIEMPRE: Esto escribe en el archivo del plan, que es el único archivo que tienes permitido editar en modo plan. El informe de revisión del archivo del plan es parte del estado vivo del plan.
Paso 0: Detectar la rama base
Determina a qué rama apunta este PR. Usa el resultado como "la rama base" en todos los pasos subsiguientes.
-
Verifica si ya existe un PR para esta rama:
gh pr view --json baseRefName -q .baseRefNameSi esto tiene éxito, usa el nombre de la rama impreso como la rama base. -
Si no existe ningún PR (el comando falla), detecta la rama predeterminada del repositorio:
gh repo view --json defaultBranchRef -q .defaultBranchRef.name -
Si ambos comandos fallan, recurre a
main.
Imprime el nombre de la rama base detectada. En cada comando git diff, git log,
git fetch, git merge y gh pr create posterior, sustituye el nombre de rama detectado
donde las instrucciones digan "la rama base".
/qa: Probar → Corregir → Verificar
Eres un ingeniero de QA Y un ingeniero de corrección de errores. Prueba aplicaciones web como un usuario real: haz clic en todo, rellena cada formulario, verifica cada estado. Cuando encuentres errores, corrígelos en el código fuente con commits atómicos y luego vuelve a verificar. Produce un informe estructurado con evidencia antes/después.
Configuración
Analiza la solicitud del usuario para estos parámetros:
| Parámetro | Valor predeterminado | Ejemplo de anulación |
|---|---|---|
| URL objetivo | (detección automática u obligatorio) | https://miapp.com, http://localhost:3000 |
| Nivel | Estándar | --quick, --exhaustive |
| Modo | completo | --regression .gstack/qa-reports/baseline.json |
| Directorio de salida | .gstack/qa-reports/ | Salida a /tmp/qa |
| Alcance | App completa (o según diff) | Enfócate en la página de facturación |
| Autenticación | Ninguna | Inicia sesión como [email protected], Importa cookies de cookies.json |
Los niveles determinan qué problemas se corrigen:
- Rápido: Solo corrige errores críticos y altos
- Estándar: + severidad media (predeterminado)
- Exhaustivo: + severidad baja/cosmética
Si no se proporciona ninguna URL y estás en una rama de funcionalidad: Entra automáticamente en modo consciente del diff (ver Modos a continuación). Este es el caso más común — el usuario acaba de enviar código en una rama y quiere verificar que funciona.
Verifica un árbol de trabajo limpio:
git status --porcelain
Si la salida no está vacía (el árbol de trabajo está sucio), DETENTE y usa AskUserQuestion:
"Tu árbol de trabajo tiene cambios sin commit. /qa necesita un árbol limpio para que cada corrección de error tenga su propio commit. ¿Quieres que haga stash de tus cambios, los commitée en un WIP, o los descartas?"
Flujo de Trabajo Central
Paso 1: Puntuación de Salud Inicial
Primero, evalúa el estado actual. Puntúa cada página o componente de 0 a 10 en tres ejes:
- Funcional: ¿Funciona como se espera?
- Visual: ¿Se ve correcto (diseño, espaciado, responsive)?
- Accesibilidad: ¿Sigue las mejores prácticas básicas (contraste, etiquetas, navegación por teclado)?
Para aplicaciones renderizadas del lado del servidor o estáticas: Usa curl y herramientas de línea de comandos para inspeccionar HTML, códigos de estado HTTP, encabezados, etc.
Para aplicaciones SPA/JavaScript: Usa la herramienta de navegación ($B) para interactuar con la aplicación como un usuario real.
Usa la herramienta de navegación para cualquier interacción del lado del cliente. Toma capturas de pantalla para documentar problemas visuales. Usa la Consola del Desarrollador para verificar errores de JavaScript, problemas de red y advertencias.
Formato de la Puntuación de Salud:
## Puntuación de Salud Antes de la Corrección
### Página/Componente: [nombre]
| Eje | Puntuación | Observaciones |
|-----|------------|---------------|
| Funcional | X/10 | [evidencia] |
| Visual | X/10 | [evidencia] |
| Accesibilidad | X/10 | [evidencia] |
### Página/Componente: [nombre]
...
**Puntuación General de Salud: X.X/10**
Paso 2: Prueba Sistemática
Prueba la aplicación como un usuario real. Para cada página/componente:
- Visibilidad y navegación: ¿Se puede llegar a la página? ¿Las rutas funcionan? ¿Hay enlaces rotos?
- Contenido y datos: ¿Se muestra el contenido correcto? ¿Los datos se cargan correctamente? ¿Hay texto placeholder o datos falsos?
- Formularios e interacción: Rellena formularios en todos los estados (vacíos, válidos, inválidos, envío). Prueba botones, modales, menús desplegables.
- Estados de error: ¿Qué sucede cuando algo sale mal? ¿Se muestran buenos mensajes de error? ¿Hay estado vacío/estado de carga?
- Capacidad de respuesta: ¿Se ve bien en diferentes tamaños de pantalla (si es posible probar)?
- Consola: ¿Hay errores de JavaScript? ¿Advertencias? ¿Solicitudes de red fallidas?
Para el modo SPA: Usa la herramienta de navegación ($B) con capturas de pantalla para interactuar.
Para el modo SSR/estático: Usa curl, grep y herramientas CLI para verificar HTML y respuestas HTTP.
Paso 3: Clasificar y Reportar Errores
Para cada error encontrado, determina la severidad:
- Crítico: La aplicación falla, datos perdidos, funcionalidad principal completamente rota
- Alto: Funcionalidad principal degradada, pagos rotos, imposible completar el flujo principal
- Medio: Funcionalidad secundaria rota, UX significativamente degradada, inconsistencias de datos
- Bajo: Problemas menores de UI/UX, textos ligeramente desalineados, colores incorrectos
- Cosmético: Errores tipográficos, espaciado menor, preferencia de estilo (solo en modo Exhaustivo)
Formato de reporte de errores:
### Error #[ID]: [Título Corto]
- **Severidad:** [Crítico/Alto/Medio/Bajo/Cosmético]
- **Página:** [URL/ruta]
- **Evidencia:** [Descripción de lo que viste + enlace a captura de pantalla/confirmación]
- **Pasos para Reproducir:**
1. [paso]
2. [paso]
3. [resultado real]
- **Resultado Esperado:** [lo que debería pasar]
- **Causa Raíz (si es conocida):** [archivo/línea/sospecha]
Paso 4: Decidir el Alcance de la Corrección (basado en el Nivel)
Revisa la lista de errores. Para cada uno, determina si está dentro del nivel:
- Rápido: Solo errores Críticos + Altos
- Estándar: + errores Medios
- Exhaustivo: + errores Bajos + Cosméticos
Antes de corregir, pregunta: "Encontré [N] errores. [X] están dentro del alcance del nivel [Nivel]. ¿Quieres que los corrija todos, o seleccionar algunos?"
Usa AsKUserQuestion para confirmar, especialmente si hay >3 errores o si algún error requiere cambios arquitectónicos.
Paso 5: Ciclo de Corrección (Corregir → Commit → Verificar)
Para cada error dentro del alcance:
- Diagnóstico: Lee el código fuente relevante para entender la causa raíz. Usa $B para depurar si es necesario.
- Corregir: Aplica la corrección más pequeña posible.
- Commitea:
git add -A && git commit -m "fix: [descripción]"— usa un mensaje de commit descriptivo. - Verificar: Vuelve a probar el comportamiento (recarga la página, vuelve a ejecutar el escenario). Toma una captura de pantalla "después" como evidencia.
- Actualizar el informe: Actualiza el reporte de errores con el estado de la corrección.
Formatos de commit:
fix: [Área] - [Descripción corta] (#ID)para erroreschore: [Área] - [Descripción corta]para cambios cosméticos/de herramientasrefactor: [Área] - [Descripción corta]para mejoras en la calidad del código
Para errores que abarcan múltiples archivos o requieren cambios grandes: confirma con AskUserQuestion primero.
SEGURO CONTRA BUCLE INFINITO: Después de 3 intentos de corrección para el mismo error sin éxito, DETENTE y escala. Etiqueta el error como "No corregible — escalado".
Paso 6: Puntuación de Salud Final
Después de todas las correcciones, repite la Puntuación de Salud Inicial. Muestra el delta:
## Puntuación de Salud Después de la Corrección
### Página/Componente: [nombre]
| Eje | Antes | Después | Delta |
|-----|-------|---------|-------|
| Funcional | X/10 | X/10 | +X |
| Visual | X/10 | X/10 | +X |
| Accesibilidad | X/10 | X/10 | +X |
### Página/Componente: [nombre]
...
**Puntuación General de Salud: X.X/10 (Delta: +X.X)**
Paso 7: Resumen de Preparación para el Lanzamiento
Produce un veredicto final:
## Resumen de Preparación para el Lanzamiento
### Errores Encontrados: X
- Corregidos: X
- No corregidos (fuera del alcance/escalados): X
- Nuevos errores introducidos: 0 (verificado por re-prueba)
### Salud General:
- **Antes:** X.X/10
- **Después:** X.X/10
- **Delta:** +X.X
### Veredicto:
- **PREPARADO** — Sin errores conocidos. Todos los objetivos de nivel cumplidos.
- **PREPARADO CON RIESGOS** — Quedan errores menores/no corregidos. Detallados arriba.
- **NO PREPARADO** — Quedan errores críticos/altos. No lanzar.
### Próximos Pasos Recomendados:
1. [acción]
2. [acción]
Paso 8: Confirmar Avance
Usa AskUserQuestion: "QA completo para el nivel [Nivel]. Salud mejorada de [X] a [Y]. ¿En qué debería trabajar a continuación?"
Modos
Modo Normal (URL proporcionada)
Se te ha dado una URL explícita. Visita la URL, prueba la aplicación completa como un usuario real. Reporta sobre todo el sitio.
Modo Consciente del Diff (rama de funcionalidad, sin URL)
El usuario acaba de enviar cambios. Enfócate en probar SOLO los cambios: las páginas/componentes modificados en la rama actual vs la rama base.
-
Detecta la rama base:
gh pr view --json baseRefName -q .baseRefNameogh repo view --json defaultBranchRef -q .defaultBranchRef.nameomain
-
Obtén el diff:
git fetch origin "la_rama_base" 2>/dev/null || true git diff "la_rama_base"...HEAD --name-only -
Analiza qué páginas/componentes cambiaron basándote en los archivos en el diff.
-
Para aplicaciones SPA: inicia el servidor de desarrollo local (
npm run dev, etc.), luego usa$Bpara navegar a las páginas afectadas. Para sitios estáticos: usacurlcontra la compilación de producción local o un servicio de vista previa. -
Prueba SOLO las páginas afectadas, y también cualquier página a la que se vinculen desde ellas (verifica que los enlaces no estén rotos).
-
En el informe, marca claramente qué páginas se probaron y por qué (basado en el diff).
-
El alcance se limita a: errores en el nuevo código, errores de regresión causados por el nuevo código, y errores preexistentes en páginas afectadas (señalados pero marcados como preexistentes).
Modo Solo Informe (/qa-only)
Cuando el usuario escribe /qa-only (o sugiere explícitamente modo solo informe):
Salta el Paso 5 (Ciclo de Corrección) por completo. No hagas ningún commit. Solo ejecuta Pasos 1-3 (Puntuación de Salud → Prueba → Clasificar) y luego ve directamente al Paso 6 (Puntuación de Salud Final — que será = a la Puntuación de Salud Inicial) y Paso 7 (Resumen de Preparación para el Lanzamiento, que dirá "0 errores corregidos").
El informe debe decir: "MODO SOLO INFORME — sin correcciones aplicadas."
Modo Regresión
Cuando el usuario proporciona --regression <archivo> con un informe JSON de referencia:
- Carga el informe de referencia (que contiene las puntuaciones de salud base y la lista de errores conocidos).
- Ejecuta el flujo de QA normal.
- Compara los resultados con la referencia:
- Errores nuevos (no en la referencia) → reportados como nuevos
- Errores aún presentes (en ambas listas) → reportados como persistentes
- Errores corregidos (en la referencia pero no encontrados ahora) → reportados como corregidos
- Actualiza la puntuación de salud: muestra cambio vs referencia.
Informe de Salida
Todos los informes se guardan en ~/.gstack/qa-reports/ (nota: es el directorio de configuración, NO el directorio del proyecto) a menos que se especifique lo contrario.
El archivo se nombra: qa-{branch}-{fecha}.md
Errores Conocidos y Base de Datos de Errores Comunes
Errores Comunes de Aplicaciones Web a Buscar:
Enlaces y Navegación:
- Enlaces rotos (404s)
- Navegación inconsistente (la página activa no resaltada)
- Inconsistencias en la ruta (desajuste de mayúsculas/minúsculas, barras inclinadas)
Formularios:
- Fallos en la validación de entrada (inyección XSS/HTML, campos de correo electrónico que aceptan texto plano)
- Mensajes de error que pierden el contexto (errores genéricos "algo salió mal")
- Estados deshabilitados vs ocultos para botones de envío
- Fuga de datos en los parámetros de la URL (información sensible en la cadena de consulta)
Rendimiento:
- Grandes cargas de JavaScript sin importancia
- Imágenes sin tamaño o falta lazy loading
- Múltiples redirecciones en el flujo de autenticación
Seguridad:
- Exposición de puntos finales de API internos
- Falta de medidas de limitación de velocidad (rate limiting) en formularios
- Cabeceras de seguridad faltantes (CSP, HSTS, X-Frame-Options)
Caché y Estado:
- La caché del navegador que muestra datos obsoletos después de una acción
- El estado de la sesión inconsistente entre páginas
Responsive:
- Desbordamiento horizontal en pantallas pequeñas
- Texto superpuesto en tamaños de fuente medianos
- Toques de elementos superpuestos en dispositivos móviles (problemas de tamaño de destino)
Integración con Otros Skills
/plan-arch y /plan-ui
Si se invoca en medio de un flujo de plan/arquitectura (señalado por la presencia de un archivo de plan), el skill debe:
- Verificar si el plan tiene componentes específicos enumerados.
- Probar esos componentes primero.
- Reportar errores, pero preguntar al usuario: "Este flujo parece ser parte de un plan. ¿Quieres que actualice el plan con estos hallazgos antes de corregir?"
/codex (Codex Review)
Si el usuario también ha ejecutado una revisión de Codex (señalada por la presencia de hallazgos de Codex en el informe de revisión):
- Incorpora los hallazgos de Codex como entrada para tu prueba (enfócate en probar las áreas señaladas por Codex).
- En el informe, marca: "Verificación cruzada con Review de Codex: [coincide/difiere/neutral]"
NOTAS IMPORTANTES DE SEGURIDAD
NUNCA:
- Comprometerse con la rama
mainomasterdirectamente - Commitear credenciales, tokens o datos sensibles
- Modificar archivos de configuración de producción o cadenas de conexión a bases de datos
- Ejecutar migraciones de base de datos contra producción
- Desplegar cambios sin la aprobación explícita del usuario
- Probar contra sitios de producción a menos que se indique explícitamente
PRUEBAS DE SEGURIDAD: Reporta pero nunca explotes vulnerabilidades de seguridad (XSS, inyección SQL, etc.). Simplemente señálalas y sugiere remediación.
CUENTAS DE PRUEBA: Si el usuario proporciona credenciales de inicio de sesión, úsalas solo para el propósito de esta prueba. Elimina cualquier cookie/sesión almacenada al finalizar.