report

Descripción general del skill report

Qué hace el skill report

El skill report es un flujo de trabajo de informes de pruebas enfocado en Playwright que convierte resultados de pruebas sin procesar en un informe de estado claro. Está pensado para situaciones en las que una persona pide un “test report”, “results summary”, “test status”, “show results”, “test dashboard” o “how did tests go”. En lugar de limitarse a resumir un log de terminal, el skill guía al agente para revisar si ya existe salida de Playwright, ejecutar las pruebas si hace falta, analizar resultados en JSON y generar un informe útil para el contexto de entrega actual.

Mejor opción para equipos de Test Automation

Este skill report es especialmente útil para ingenieros de Test Automation, QA leads, desarrolladores que usan Playwright y agentes que trabajan dentro de repositorios donde hay que resumir resultados de pruebas con rapidez. Encaja muy bien cuando los equipos ya usan test-results/, playwright-report/, GitHub Actions, webhooks de Slack o informes al estilo TestRail. Su función principal no es generar pruebas, sino interpretar lo que ocurrió después de la ejecución y comunicar el estado de las pruebas.

Por qué es más útil que un prompt genérico

Un prompt genérico como “summarize my tests” suele pasar por alto dónde guarda Playwright los resultados, si conviene volver a ejecutar las pruebas y a dónde debe ir el informe final. El skill report incorpora decisiones de flujo de trabajo: inspeccionar artefactos existentes, ejecutar Playwright con reporteros JSON/HTML/list cuando falten resultados, extraer conteos de pruebas aprobadas, fallidas, omitidas y flaky, identificar pruebas fallidas y mensajes, y elegir un destino como Markdown, informe HTML, artefacto de CI, Slack o TestRail cuando el entorno lo permite.

Notas importantes antes de adoptarlo

El skill upstream es ligero: la ruta visible del repositorio contiene solo SKILL.md, sin scripts auxiliares, reglas, referencias ni recursos incluidos. Eso facilita revisarlo y adaptarlo, pero también significa que el agente debe apoyarse en la configuración local de Playwright y en las variables de entorno disponibles. Antes de instalarlo, confirma que tu proyecto usa Playwright o que te resulta cómodo adaptar el flujo a otro runner de pruebas de JavaScript.

Cómo usar el skill report

Contexto de instalación de report

Instala el skill desde la ruta del repositorio usada por el directorio:

npx skills add alirezarezvani/claude-skills --skill report

Después de instalarlo, revisa primero el código fuente del skill:

engineering-team/playwright-pro/skills/report/SKILL.md

En la vista previa publicada del skill no hay carpetas de soporte adicionales, así que SKILL.md es la guía operativa principal. En tu propio repositorio, revisa playwright.config.*, package.json, .github/workflows/, test-results/ y playwright-report/ para entender cómo se produce la salida de las pruebas y hacia dónde deben enviarse los informes.

Entradas que necesita el skill

Para usar report de forma fiable, dale al agente contexto suficiente para evitar suposiciones:

• Si las pruebas ya se ejecutaron
• El comando que normalmente se usa para las pruebas de Playwright
• La ubicación de los artefactos de resultados, si no es la estándar
• Si los reintentos están habilitados, porque las pruebas flaky se infieren a partir del comportamiento de retry
• El formato de salida deseado: Markdown, comentario en PR, resumen en Slack, envío a TestRail o informe HTML local
• Cualquier restricción del entorno, como “do not rerun tests” o “CI only”

Prompt débil:

Make a test report.

Prompt más sólido:

Use the report skill for this Playwright project. Do not rerun tests unless no recent results exist. Check test-results/ and playwright-report/, parse JSON output if available, summarize passed/failed/skipped/flaky counts, list failed tests with error messages, and produce a Markdown report for the release channel.

Flujo práctico para usar report

Un buen flujo de trabajo para generar un informe con report es:

1. Revisar los artefactos existentes con ls -la test-results/ playwright-report/ 2>/dev/null.
2. Si no existe ningún resultado utilizable y está permitido volver a ejecutar las pruebas, ejecutar:

   npx playwright test --reporter=json,html,list 2>&1 | tee test-output.log
   

3. Analizar la salida JSON para obtener totales, duración, fallos, pruebas omitidas y reintentos.
4. Detectar destinos:
   • TESTRAIL_URL sugiere que puede estar disponible la publicación en TestRail.
   • SLACK_WEBHOOK_URL sugiere que se puede publicar un resumen en Slack.
   • .github/workflows/ sugiere que los informes de CI/PR pueden ser relevantes.
   • playwright-report/ sugiere que el informe HTML se puede abrir o servir.
5. Generar siempre un resumen en Markdown, salvo que el usuario pida explícitamente un único destino.

Consejos para mejorar la calidad de la salida

Indica al agente qué decisión debe respaldar el informe. Un release manager necesita riesgos y bloqueadores; un desarrollador necesita specs fallidas, stack traces y comandos de reproducción; un QA lead quizá necesite conteos de pruebas flaky y tendencias de duración. Si el informe se va a pegar en un PR, pide un resumen compacto. Si es para una revisión de incidente, solicita que los fallos se agrupen por suite, navegador o patrón de error.

Preguntas frecuentes sobre el skill report

¿report es solo para Playwright?

El skill está escrito alrededor de comandos, carpetas y reporteros de Playwright, por lo que es más preciso para Test Automation con Playwright. Puedes adaptar su estructura a Jest, Cypress u otros runners, pero tendrás que ajustar los comandos, las rutas de artefactos y la detección de pruebas flaky. Si tu repositorio no tiene artefactos de pruebas ni configuración de Playwright, un prompt normal puede ser igual de eficaz.

¿report ejecuta pruebas automáticamente?

Puede guiar al agente para ejecutar pruebas si no encuentra resultados recientes, usando npx playwright test --reporter=json,html,list. Sin embargo, conviene que indiques si está permitido volver a ejecutarlas. En suites grandes, repetir pruebas puede ser lento, costoso o inapropiado después de un fallo en CI, donde el entorno original importa.

¿Qué genera el skill report?

La salida predeterminada es un informe de pruebas en Markdown con conteos de pruebas aprobadas, fallidas, omitidas y flaky, duración total y detalles de las pruebas fallidas. Según tu entorno, el flujo también puede enrutar resultados hacia TestRail, Slack, artefactos de GitHub Actions o comentarios en PR, o hacia el informe HTML de Playwright.

¿Cuándo no debería instalar report?

Omite o pospón la instalación si tu equipo no usa Playwright, ya tiene una plataforma de reporting dedicada con APIs estrictas o necesita analítica histórica más allá de una sola ejecución de pruebas. Este skill es un prompt de flujo de trabajo conciso, no un servicio completo de reporting, base de datos, dashboard ni sistema de gestión de pruebas flaky.

Cómo mejorar el skill report

Mejora las entradas de report antes de pedir el informe

La forma más rápida de mejorar los resultados de report es definir los límites de ejecución. Incluye el comando de pruebas, las rutas de artefactos, el destino, la audiencia y la política de reejecución. Por ejemplo:

Generate a report for the CI Playwright run. Use existing artifacts only. Look in test-results/ and playwright-report/. Output a PR-ready Markdown summary with top failures, flaky tests, and whether the build should block merge.

Esto evita que el agente pierda tiempo repitiendo pruebas o genere un nivel de detalle equivocado.

Gestiona los modos de fallo habituales

Entre los problemas comunes están la ausencia de salida JSON, artefactos desactualizados, logs enormes y reintentos ambiguos. Si no hay JSON disponible, pide al agente que use como alternativa test-output.log y los metadatos del informe HTML. Si los artefactos pueden estar obsoletos, exige comprobaciones de timestamp. Si los logs son demasiado grandes, solicita que se agrupen por título de prueba fallida y por el primer mensaje de error significativo, en lugar de pegar stack traces completos.

Adapta report al flujo de trabajo de tu equipo

Como el skill no incluye scripts empaquetados, las mejoras específicas de cada equipo suelen hacerse añadiendo convenciones locales. Documenta tu plantilla de informe preferida, las reglas del canal de Slack, el mapeo de proyectos de TestRail, el patrón de URL de artefactos de CI y las etiquetas de severidad. Luego menciona esas convenciones en el prompt para que el skill report produzca una salida alineada con tu proceso de release.

Itera después del primer informe

Trata el primer informe como un borrador. Haz preguntas de seguimiento como:

• “Group failures by root cause.”
• “Separate product defects from test infrastructure failures.”
• “Add rerun recommendations for flaky tests.”
• “Make this suitable for a non-technical release update.”
• “Include exact commands to reproduce the failed specs.”

Así el informe se mantiene centrado en decisiones, no solo en conteos.