report

Visão geral do report skill

O que o report skill faz

O report skill é um fluxo de trabalho de relatório de testes focado em Playwright, feito para transformar resultados brutos de testes em um relatório de status claro. Ele foi pensado para situações em que o usuário pede “test report”, “results summary”, “test status”, “show results”, “test dashboard” ou “how did tests go”. Em vez de apenas resumir um log de terminal, o skill orienta o agente a verificar saídas existentes do Playwright, executar testes quando necessário, interpretar resultados em JSON e gerar um relatório útil para o contexto atual de entrega.

Melhor uso para equipes de Test Automation

Este report skill é mais indicado para engenheiros de Test Automation, líderes de QA, desenvolvedores que usam Playwright e agentes trabalhando dentro de repositórios onde os resultados de testes precisam ser resumidos rapidamente. Ele se encaixa especialmente bem quando as equipes já usam test-results/, playwright-report/, GitHub Actions, Slack webhooks ou relatórios no estilo TestRail. Sua função principal não é gerar testes; é interpretar o que aconteceu depois da execução e entregar o status dos testes.

Por que ele é mais útil do que um prompt genérico

Um prompt genérico como “summarize my tests” muitas vezes deixa passar onde o Playwright armazena os resultados, se os testes devem ser executados novamente e para onde o relatório final deve ir. O report skill adiciona decisões de fluxo: inspecionar artefatos existentes, executar Playwright com reporters JSON/HTML/list quando os resultados não existem, extrair contagens de testes passados/com falha/pulados/flaky, identificar testes com falha e mensagens, e escolher um destino como Markdown, relatório HTML, artefato de CI, Slack ou TestRail quando o ambiente oferece suporte.

Observações importantes antes de adotar

O skill upstream é leve: o caminho visível do repositório contém apenas SKILL.md, sem scripts auxiliares, regras, referências ou assets incluídos. Isso facilita a inspeção e a adaptação, mas também significa que seu agente precisa depender da configuração local do Playwright e das variáveis de ambiente disponíveis. Antes de instalar, confirme que seu projeto usa Playwright ou que você está confortável em adaptar o fluxo para outro test runner JavaScript.

Como usar o report skill

Contexto de instalação do report

Instale o skill a partir do caminho de repositório usado pelo diretório:

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

Depois da instalação, inspecione primeiro o código-fonte do skill:

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

Não há pastas extras de suporte na prévia publicada do skill, então SKILL.md é o guia operacional principal. No seu próprio repositório, verifique playwright.config.*, package.json, .github/workflows/, test-results/ e playwright-report/ para entender como a saída dos testes é gerada e para onde os relatórios devem ser encaminhados.

Entradas de que o skill precisa

Para usar o report com confiabilidade, dê ao agente contexto suficiente para evitar suposições:

• Se os testes já foram executados
• O comando normalmente usado para testes Playwright
• Localização dos artefatos de resultado, se não for padrão
• Se retries estão habilitados, porque testes flaky são inferidos pelo comportamento de retry
• Formato de saída desejado: Markdown, comentário em PR, resumo no Slack, envio para TestRail ou relatório HTML local
• Restrições de ambiente, como “do not rerun tests” ou “CI only”

Prompt fraco:

Make a test report.

Prompt mais forte:

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.

Fluxo prático de uso do report

Um bom fluxo guiado para o report é:

1. Verificar artefatos existentes com ls -la test-results/ playwright-report/ 2>/dev/null.
2. Se não houver resultado utilizável e uma nova execução for permitida, executar:

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

3. Interpretar a saída JSON para obter totais, duração, falhas, testes pulados e retries.
4. Detectar destinos:
   • TESTRAIL_URL sugere que a publicação no TestRail pode estar disponível.
   • SLACK_WEBHOOK_URL sugere que um resumo no Slack pode ser publicado.
   • .github/workflows/ sugere que relatórios de CI/PR podem ser relevantes.
   • playwright-report/ sugere que o relatório HTML pode ser aberto ou servido.
5. Sempre gerar um resumo em Markdown, a menos que o usuário peça apenas um único destino.

Dicas para melhorar a qualidade da saída

Diga ao agente qual decisão o relatório precisa apoiar. Um gerente de release precisa de riscos e bloqueadores; um desenvolvedor precisa de specs com falha, stack traces e comandos de reprodução; um líder de QA pode precisar de contagens de testes flaky e tendências de duração. Se o relatório será colado em um PR, peça um resumo compacto. Se for para revisão de incidente, peça agrupamento de falhas por suíte, navegador ou padrão de erro.

FAQ do report skill

O report serve apenas para Playwright?

O skill foi escrito em torno de comandos, pastas e reporters do Playwright, então é mais preciso para Test Automation com Playwright. Você pode adaptar sua estrutura para Jest, Cypress ou outros runners, mas comandos, caminhos de artefatos e detecção de testes flaky precisarão de ajustes. Se o seu repositório não tem artefatos de teste nem configuração de Playwright, um prompt comum pode ser igualmente eficaz.

O report executa testes automaticamente?

Ele pode orientar o agente a executar testes se nenhum resultado recente for encontrado, usando npx playwright test --reporter=json,html,list. Ainda assim, você deve dizer se novas execuções são permitidas. Em suítes grandes, reexecutar testes pode ser lento, caro ou inadequado depois de uma falha em CI, quando o ambiente original é importante.

O que o report skill gera?

A saída padrão é um relatório de testes em Markdown com contagens de testes passados, com falha, pulados e flaky, duração total e detalhes dos testes com falha. Dependendo do seu ambiente, o fluxo também pode encaminhar resultados para TestRail, Slack, artefatos ou comentários de PR no GitHub Actions, ou para o relatório HTML do Playwright.

Quando eu não deveria instalar o report?

Evite ou adie a instalação se sua equipe não usa Playwright, já tem uma plataforma dedicada de relatórios com APIs rígidas ou precisa de analytics históricos além de uma única execução de testes. Este skill é um prompt de fluxo de trabalho conciso, não um serviço completo de relatórios, banco de dados, dashboard ou sistema de gestão de testes flaky.

Como melhorar o report skill

Melhore as entradas do report antes de pedir

A forma mais rápida de melhorar os resultados do report é fornecer limites de execução. Inclua o comando de teste, caminhos de artefatos, destino, público e política de reexecução. Por exemplo:

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.

Isso evita que o agente perca tempo reexecutando testes ou produza um nível de detalhe inadequado.

Lide com modos de falha comuns

Problemas comuns incluem ausência de saída JSON, artefatos desatualizados, logs enormes e retries ambíguos. Se o JSON não estiver disponível, peça ao agente para usar test-output.log e os metadados do relatório HTML como fallback. Se os artefatos puderem estar desatualizados, exija verificações de timestamp. Se os logs forem grandes demais, peça agrupamento por título do teste com falha e pela primeira mensagem de erro relevante, em vez de colar stack traces completos.

Adapte o report ao fluxo da sua equipe

Como o skill não traz scripts incluídos, a melhoria específica da equipe geralmente acontece com a adição de convenções locais. Documente seu template de relatório preferido, regras de canal no Slack, mapeamento de projeto no TestRail, padrão de URL de artefatos de CI e labels de severidade. Depois, referencie essas convenções no prompt para que o report skill produza uma saída alinhada ao seu processo de release.

Itere depois do primeiro relatório

Trate o primeiro relatório como um rascunho. Faça perguntas de acompanhamento 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.”

Assim, o report continua focado em decisões, não apenas em contagens.