Playwright Report Generator

Every other skill in this toolkit already reports its own results — flow-runner's step table, bug-triage's per-bug writeup, the CSVs from scenario-mapper and accessibility-audit. This skill isn't another version of that. It's the layer above: pulling together whatever's accumulated across a testing cycle — possibly several runs, several skills, spread over days — into one document a human can read once and understand where things stand, without re-reading every individual artifact.

Before you start

No Playwright or MCP tool access needed for this one — it's a reading and writing task, not a browsing task. What it does need is access to the artifact files the other skills produced: CSVs, markdown reports, and the evidence directories they reference. If you don't know where those live, ask rather than guessing at a path.

Core principles (and why)

Synthesize, don't re-run, and never fabricate. If accessibility wasn't audited this cycle, the report says so — it does not estimate what an audit probably would have found. Missing coverage is a gap to report, not a gap to paper over. If asked to report on something nothing has actually tested, say that plainly and point to which skill would need to run first.

Lead with what matters, not with everything given equal weight. A report that lists forty passing checks and one critical failure with the same visual weight buries the one thing the reader actually needs to act on. Executive summary and top issues come first; full detail is available below but isn't what a skimming reader needs to see first.

State what wasn't covered, not just what was. Silence about a gap reads as "checked and fine" to someone who wasn't in the room. If cross-browser testing only covered Chromium this cycle, or a comprehensive scenario pass was never run and only sanity was, the Scope section says so explicitly.

Preserve each source skill's own severity — don't re-score. flow-runner's pass/fail, bug-triage's severity and confidence, axe's impact level, scenario-mapper's priority: carry these through as given rather than inventing a unified scale that quietly loses the original reasoning. Some normalization for an at-a-glance table is fine (mapping different scales to a simple status icon), but the source severity should still be visible once you're in the details.

Reconcile cross-references instead of double-counting. bug-triage reports explicitly point back to the flow-runner failure they investigated; network-assertion checks are often already folded into whichever flow-runner report they were part of. If you present both the original and the investigation (or the folded-in check) as separate, unrelated findings, the same issue silently inflates the count. Merge them.