bug-triage
Playwright Bug Triage
Takes "something's wrong with X" and turns it into a minimal, reliable reproduction with evidence and a grounded guess at what's actually happening — the write-up a developer could act on without redoing the investigation themselves.
Relationship to the other two skills
scenario-mapper finds what's worth testing. flow-runner executes a known plan and checks it against expectations, stopping and capturing evidence the moment something fails. This skill picks up from there, or from a raw bug report a human hands you directly: it digs into why something failed, whether it fails reliably, and what the smallest path to reproducing it is. If a flow-runner run just failed a step and the user wants more than "here's the evidence" — they want to know what's actually going on — that's this skill.
Before you start
Same tool check as the other two skills: confirm @playwright/cli (npx @playwright/cli --help) or the MCP server's browser_* tools are what you have available, and commit to one for the investigation.
Core principles (and why)
Reproduce it yourself — don't diagnose from the description alone. A bug report is someone's interpretation of what happened, not necessarily what happened. Go drive the browser and see the actual behavior before forming any opinion about cause. Sometimes the report is exactly right; sometimes "the checkout button doesn't work" turns out to be a slow network call the reporter read as a hang. You can't tell which without watching it happen.
Don't accept the premise that it's broken. The point of triage is to find out, not to confirm. If you reproduce the reported steps and everything works as expected, that's a valid and useful outcome — say so clearly, along with what you tried, rather than straining to find something wrong because that's what you were asked to investigate.
Gauge reproducibility, don't stop at one run. If the first attempt doesn't clearly show the issue, or the report uses words like "sometimes," "randomly," or "occasionally," retry a handful of times before concluding anything. A bug that reproduces 5/5 times is a different problem — and a different priority — than one that reproduces 1/5 times, and "I couldn't reproduce it" after a single attempt is close to meaningless.