report

report skill の概要

report skill でできること

report skill は、Playwright を中心にしたテストレポート作成ワークフローです。生のテスト結果を、状況がひと目で分かるステータスレポートに整理します。ユーザーが「test report」「results summary」「test status」「show results」「test dashboard」「how did tests go」といった依頼をした場面を想定しています。単にターミナルログを要約するだけではなく、既存の Playwright 出力を確認し、必要に応じてテストを実行し、JSON 結果を解析し、現在のデリバリー文脈に合った実用的なレポートを生成するようエージェントを導きます。

Test Automation チームに向いているケース

この report skill は、Test Automation エンジニア、QA リード、Playwright を使う開発者、リポジトリ内でテスト結果をすばやく要約する必要があるエージェントに特に向いています。すでに test-results/、playwright-report/、GitHub Actions、Slack webhooks、TestRail 風のレポート運用を使っているチームとは相性が良いです。主な役割はテスト生成ではなく、実行後の結果を読み解き、テスト状況を届けることです。

汎用プロンプトより役立つ理由

汎用的な「テストを要約して」というプロンプトでは、Playwright がどこに結果を保存するのか、テストを再実行すべきか、最終レポートをどこへ出すべきかを見落としがちです。report skill は、既存アーティファクトの確認、結果がない場合の JSON/HTML/list reporter 付き Playwright 実行、pass/fail/skip/flaky 件数の抽出、失敗テストとメッセージの特定、Markdown、HTML report、CI artifact、Slack、TestRail など環境に応じた出力先の選択まで、ワークフロー上の判断を補います。

導入前に知っておきたい注意点

上流の skill は軽量です。公開されているリポジトリパスで確認できるのは SKILL.md のみで、補助スクリプト、ルール、参照資料、同梱アセットはありません。そのため中身を確認して適応するのは簡単ですが、エージェントはローカルの Playwright 設定と利用可能な環境変数に依存します。インストール前に、プロジェクトが Playwright を使っているか、またはこのワークフローを別の JavaScript テストランナー向けに調整できるかを確認してください。

report skill の使い方

report のインストール前提

ディレクトリで使われているリポジトリパスから skill をインストールします。

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

インストール後は、まず skill のソースを確認します。

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

公開プレビュー上の skill には追加のサポートフォルダがないため、SKILL.md が主な運用ガイドになります。自分のリポジトリでは、playwright.config.*、package.json、.github/workflows/、test-results/、playwright-report/ を確認し、テスト出力がどのように生成され、レポートをどこへ流すべきかを把握してください。

skill に渡すべき入力

report を安定して使うには、エージェントが推測しなくて済むだけの文脈を渡します。

• テストがすでに実行済みかどうか
• Playwright テストで通常使うコマンド
• 標準ではない場合の結果アーティファクトの場所
• retry が有効かどうか。flaky test は retry の挙動から推定されるため
• 希望する出力形式: Markdown、PR comment、Slack summary、TestRail push、local HTML report
• 「テストを再実行しない」「CI only」などの環境制約

弱いプロンプト:

Make a test report.

より良いプロンプト:

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.

実務での report 活用フロー

実用的な report ガイドの流れは次のとおりです。

1. ls -la test-results/ playwright-report/ 2>/dev/null で既存アーティファクトを確認する。
2. 利用できる結果がなく、再実行が許可されている場合は、次を実行する。

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

3. JSON 出力から合計、実行時間、失敗、スキップ、retry を解析する。
4. 出力先を検出する。
   • TESTRAIL_URL があれば、TestRail への公開が利用できる可能性がある。
   • SLACK_WEBHOOK_URL があれば、Slack summary を投稿できる可能性がある。
   • .github/workflows/ があれば、CI/PR レポートが関係する可能性がある。
   • playwright-report/ があれば、HTML report を開く、または配信できる可能性がある。
5. ユーザーが単一の出力先だけを求めていない限り、必ず Markdown summary を生成する。

出力品質を高めるコツ

そのレポートがどの判断を支えるものなのかをエージェントに伝えてください。リリースマネージャーにはリスクとブロッカーが必要です。開発者には失敗した spec、stack trace、再現コマンドが必要です。QA リードには flaky test の件数や実行時間の傾向が必要な場合があります。PR に貼るレポートならコンパクトな要約を依頼します。インシデントレビュー向けなら、suite、browser、error pattern ごとの失敗グルーピングを依頼するとよいでしょう。

report skill FAQ

report は Playwright 専用ですか？

この skill は Playwright のコマンド、フォルダ、reporter を前提に書かれているため、Playwright Test Automation で最も正確に機能します。構成自体は Jest、Cypress、その他の runner にも応用できますが、コマンド、アーティファクトパス、flaky-test 検出は調整が必要です。リポジトリにテストアーティファクトがなく、Playwright 設定もない場合は、通常のプロンプトのほうが同程度に有効なこともあります。

report はテストを自動実行しますか？

最近の結果が見つからない場合、npx playwright test --reporter=json,html,list を使ってテストを実行するようエージェントを誘導できます。ただし、再実行を許可するかどうかは明示してください。大規模な suite では、再実行に時間やコストがかかることがあります。また、CI 失敗後のように元の環境条件が重要な場合、再実行が不適切なこともあります。

report skill は何を生成しますか？

デフォルトの出力は、passed、failed、skipped、flaky test の件数、総実行時間、失敗テストの詳細を含む Markdown のテストレポートです。環境によっては、TestRail、Slack、GitHub Actions artifacts や PR comments、Playwright HTML report へ結果を流すワークフローにも対応できます。

report をインストールしないほうがよい場合は？

チームが Playwright を使っていない場合、厳密な API を持つ専用レポーティング基盤がすでにある場合、または単一のテスト実行を超えた履歴分析が必要な場合は、インストールを見送るか後回しにしてください。この skill は簡潔なワークフロープロンプトであり、完全なレポーティングサービス、データベース、ダッシュボード、flaky-test 管理システムではありません。

report skill を改善する方法

依頼前に report の入力情報を整える

report の結果を最も手早く改善する方法は、実行範囲を明確にすることです。テストコマンド、アーティファクトパス、出力先、読者、再実行ポリシーを含めてください。例:

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.

これにより、エージェントが不要なテスト再実行に時間を使ったり、必要とする粒度と違うレポートを作ったりするのを防げます。

よくある失敗パターンに備える

よくある問題には、JSON 出力がない、アーティファクトが古い、ログが巨大、retry の解釈があいまい、といったものがあります。JSON が利用できない場合は、test-output.log と HTML report のメタデータにフォールバックするようエージェントに依頼してください。アーティファクトが古い可能性があるなら、timestamp の確認を必須にします。ログが大きすぎる場合は、stack trace 全文を貼るのではなく、失敗テスト名と最初の意味のあるエラーメッセージでグルーピングするよう依頼します。

自チームのワークフローに report を合わせる

この skill には同梱スクリプトがないため、チーム固有の改善はたいていローカルの運用ルール追加で行います。推奨するレポートテンプレート、Slack channel rules、TestRail project mapping、CI artifact URL pattern、severity labels を文書化してください。そのうえで、それらのルールをプロンプト内で参照すれば、report skill はチームのリリースプロセスに合った出力を作りやすくなります。

最初の report の後に調整する

最初の report はドラフトとして扱います。次のような追加依頼をしてください。

• “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.”

これにより、レポートは単なる件数の一覧ではなく、意思決定に役立つ内容に保たれます。