Communitygithub.com

RageClick

Prueba un flujo de trabajo web local con clics repetidos, navegación, archivos no válidos, recargas y solicitudes retardadas; produce evidencia reproducible de fallos en los objetivos.

¿Qué es RageClick?

RageClick es una habilidad diseñada para desarrolladores que desean probar la robustez de sus aplicaciones web locales. Convierte una URL y un objetivo de usuario en una secuencia corta y reproducible que revela comportamientos prometidos pero fallidos. La habilidad se basa en Playwright para ejecutar pruebas en un contexto de navegador aislado, bloqueando las solicitudes fuera del origen exacto, y genera evidencia completa: informes, capturas de pantalla, trazas, video y scripts de repetición. Es compatible con aplicaciones locales y entornos de prueba autorizados, permitiendo a los desarrolladores identificar fallos de aserción, minimizar secuencias de prueba y verificar correcciones sin alterar datos reales. Además, incluye guías claras sobre cómo interpretar los resultados, evitando falsas conclusiones y manteniendo la integridad de las pruebas al repetir los casos al menos dos veces antes de confirmar un fallo.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/K-kiron/RageClick/tree/main/skills/rageclick

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

¿Qué hace RageClick?

Convierte una URL y un objetivo de usuario en una secuencia corta y reproducible que rompe un comportamiento prometido. Utilice la herramienta de navegador existente para inspeccionar la página real, luego el ejecutor de Playwright incluido para obtener evidencia repetible. Esta habilidad no evalúa el diseño visual ni pretende representar una investigación real de usuarios.

Alcance y criterios de éxito

Trabaje solo en entornos propios, aplicaciones locales o entornos de prueba explícitamente autorizados. El ejecutor incluido solo acepta URLs de bucle invertido, inicia un contexto de navegador nuevo y bloquea solicitudes fuera del origen exacto. Una aplicación local aún puede mutar un backend real a través de su servidor: establezca datos sintéticos y una cuenta desechable antes de enviar. No compre, envíe mensajes, elimine datos valiosos ni cambie la configuración de acceso. El permiso existente cubre únicamente el flujo de trabajo acordado.

A partir del objetivo del usuario y la interfaz observada, identifique un invariante concreto: un proyecto para una intención de envío, la recuperación después de un archivo no válido, o un borrador que sobrevive a un guardado prometido. Si el contrato es ambiguo, registre una observación o pregunte sobre ese comportamiento específico en lugar de inventar un defecto. Registre la versión de la aplicación o el commit; use unknown si no está disponible.

Explorar, perturbar, repetir

  1. Inspeccione la página actual usando una herramienta de navegador disponible o el código fuente objetivo. Seleccione etiquetas estables, roles o identificadores de prueba a partir de la evidencia real. Ejecute primero el flujo de trabajo exitoso común. Si no puede completarse, resuelva ese requisito previo o repórtelo por separado.

  2. Lea references/plans.md para escribir un plan JSON. Elija las plantillas aplicables de references/perturbations.md. Cambie una dimensión por caso. Los contextos de navegador nuevos aíslan el estado del navegador, pero los datos del servidor requieren un restablecimiento conocido o una cuenta desechable única. No asuma que un navegador nuevo restablece una base de datos.

  3. Ejecute desde este directorio de habilidad después de npm ci y npx playwright install chromium:

    node scripts/run.mjs --url http://127.0.0.1:3000 --plan /absolute/path/case.json --out /absolute/path/evidence --app-version COMMIT
    

    El directorio de salida debe ser nuevo. El ejecutor escribe un informe legible, el plan exacto, los resultados de los pasos, capturas de pantalla, traza, video y script de repetición. No puede inferir un objetivo o selectores por sí mismo; la habilidad hace ese trabajo. Mantenga la evidencia generada fuera del repositorio objetivo a menos que se solicite como un ejemplo duradero.

  4. Trate observed_failure como una discrepancia de aserción, no una causa raíz establecida. Repita el mismo caso en estado nuevo al menos dos veces antes de llamarlo reproducible. Capture fallos y aciertos; nunca descarte repeticiones contradictorias. execution_error significa que una acción, selector, navegador o límite falló y no es evidencia de producto. Registre comentarios subjetivos de UX por separado de las aserciones objetivas.

  5. Minimice la secuencia sin cambiar el fallo, luego use replay.mjs como un comando de regresión (salida 0 pasa, 1 discrepancia de aserción, 2 error de ejecución/configuración). Si está autorizado para corregir la aplicación, vuelva a ejecutar el plan idéntico contra la versión corregida y verifique que la ruta común sigue pasando. Nunca cambie la aserción para fabricar un resultado exitoso.

Reporte el contrato violado, el estado real y esperado, el número de ocurrencias, las versiones de la aplicación/navegador, los comandos exactos y las rutas de evidencia. Indique cuándo faltan video, traza, línea base, restablecimiento o repetibilidad. Redacte credenciales y datos personales antes de compartir capturas; las trazas pueden contener datos completos de solicitud/respuesta. Esta habilidad no implica publicación ni mensajes externos.

Límites

El ejecutor usa Chromium, selectores CSS, eventos de puntero nativos, archivos en línea sintéticos y retrasos de solicitud acotados. Un retraso de solicitud no es limitación de ancho de banda ni pérdida de paquetes. No puede automatizar servidores remotos de prueba, redirecciones HTTP (incluyendo redirecciones del mismo origen), respuestas en flujo, inicio de sesión en múltiples orígenes, service workers, WebSockets o JavaScript arbitrario. Las respuestas se almacenan en búfer a través de Playwright con redirecciones y reintentos de transporte desactivados, por lo que la fidelidad de flujo y temporización de red es limitada. Las pruebas de credenciales de navegador y política de Set-Cookie tampoco son compatibles: el transporte de API puede almacenar cookies de respuesta de manera diferente a la obtención del navegador. Para flujos de trabajo no compatibles, use una herramienta de navegador autorizada ya disponible y preserve el mismo contrato de evidencia; marque las perturbaciones no compatibles explícitamente. No debilite el límite de origen del ejecutor para hacer que una prueba pase.

Skills relacionados