report

Overview of report skill

What the report skill does

The report skill is a Playwright-focused test reporting workflow for turning raw test results into a clear status report. It is designed for moments when a user asks for a “test report,” “results summary,” “test status,” “show results,” “test dashboard,” or “how did tests go.” Instead of only summarizing a terminal log, the skill guides the agent to check for existing Playwright output, run tests if needed, parse JSON results, and generate a useful report for the current delivery context.

Best fit for Test Automation teams

This report skill is best for Test Automation engineers, QA leads, developers using Playwright, and agents working inside repositories where test results need to be summarized quickly. It fits especially well when teams already use test-results/, playwright-report/, GitHub Actions, Slack webhooks, or TestRail-style reporting. Its main job is not test generation; it is post-run interpretation and delivery of test status.

Why it is more useful than a generic prompt

A generic “summarize my tests” prompt often misses where Playwright stores results, whether tests should be rerun, and where the final report should go. The report skill adds workflow decisions: inspect existing artifacts, run Playwright with JSON/HTML/list reporters when results are missing, extract pass/fail/skip/flaky counts, identify failed tests and messages, and choose a destination such as Markdown, HTML report, CI artifact, Slack, or TestRail when the environment supports it.

Important adoption notes

The upstream skill is lightweight: the visible repository path contains SKILL.md only, with no helper scripts, rules, references, or bundled assets. That makes it easy to inspect and adapt, but it also means your agent must rely on local Playwright configuration and available environment variables. Before installing, confirm your project uses Playwright or that you are comfortable adapting the workflow to another JavaScript test runner.

How to Use report skill

report install context

Install the skill from the repository path used by the directory:

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

After installation, inspect the skill source first:

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

There are no extra support folders in the published skill preview, so SKILL.md is the main operating guide. In your own repository, check playwright.config.*, package.json, .github/workflows/, test-results/, and playwright-report/ to understand how test output is produced and where reports should be routed.

Inputs the skill needs

For reliable report usage, give the agent enough context to avoid guessing:

• Whether tests have already been run
• The command normally used for Playwright tests
• Location of result artifacts, if nonstandard
• Whether retries are enabled, because flaky tests are inferred from retry behavior
• Desired output format: Markdown, PR comment, Slack summary, TestRail push, or local HTML report
• Any environment constraints, such as “do not rerun tests” or “CI only”

Weak prompt:

Make a test report.

Stronger prompt:

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.

Practical report usage workflow

A good report guide workflow is:

1. Check existing artifacts with ls -la test-results/ playwright-report/ 2>/dev/null.
2. If no usable result exists and rerunning is allowed, run:

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

3. Parse JSON output for totals, duration, failures, skipped tests, and retries.
4. Detect destinations:
   • TESTRAIL_URL suggests TestRail publishing may be available.
   • SLACK_WEBHOOK_URL suggests a Slack summary can be posted.
   • .github/workflows/ suggests CI/PR reporting may be relevant.
   • playwright-report/ suggests the HTML report can be opened or served.
5. Always generate a Markdown summary unless the user asks for a single destination only.

Tips for better output quality

Tell the agent what decision the report supports. A release manager needs risk and blockers; a developer needs failing specs, stack traces, and reproduction commands; a QA lead may need flaky-test counts and duration trends. If the report will be pasted into a PR, request a compact summary. If it is for incident review, ask for failure grouping by suite, browser, or error pattern.

report skill FAQ

Is report only for Playwright?

The skill is written around Playwright commands, folders, and reporters, so it is most accurate for Playwright Test Automation. You can adapt its structure to Jest, Cypress, or other runners, but commands, artifact paths, and flaky-test detection will need adjustment. If your repository has no test artifacts and no Playwright setup, ordinary prompting may be just as effective.

Does report run tests automatically?

It can guide the agent to run tests if no recent results are found, using npx playwright test --reporter=json,html,list. However, you should state whether reruns are allowed. In large suites, rerunning tests can be slow, expensive, or inappropriate after a CI failure where the original environment matters.

What does the report skill generate?

The default output is a Markdown test report with counts for passed, failed, skipped, flaky tests, total duration, and failed-test details. Depending on your environment, the workflow may also route results toward TestRail, Slack, GitHub Actions artifacts or PR comments, or the Playwright HTML report.

When should I not install report?

Skip or postpone install if your team does not use Playwright, has a dedicated reporting platform with strict APIs, or needs historical analytics beyond a single test run. This skill is a concise workflow prompt, not a full reporting service, database, dashboard, or flaky-test management system.

How to Improve report skill

Improve report inputs before asking

The fastest way to improve report results is to provide execution boundaries. Include the test command, artifact paths, destination, audience, and rerun policy. For example:

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.

This prevents the agent from wasting time rerunning tests or producing the wrong level of detail.

Handle common failure modes

Common issues include missing JSON output, stale artifacts, huge logs, and ambiguous retries. If JSON is unavailable, ask the agent to fall back to test-output.log and the HTML report metadata. If artifacts may be stale, require timestamp checks. If logs are too large, request grouping by failed test title and first meaningful error message rather than pasting full stack traces.

Adapt report to your team workflow

Because the skill has no bundled scripts, team-specific improvement usually happens by adding local conventions. Document your preferred report template, Slack channel rules, TestRail project mapping, CI artifact URL pattern, and severity labels. Then reference those conventions in the prompt so the report skill can produce output that matches your release process.

Iterate after the first report

Treat the first report as a draft. Ask follow-up questions such as:

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

This keeps the report focused on decisions, not just counts.