playwright-triage

name playwright-triage description Triage a Playwright bug report by reproducing it from the information in the issue. Use when asked to triage, reproduce, or verify a GitHub issue (a new bug report, or an existing report with a new comment). user_invocable true Playwright Issue Triage Triage a GitHub issue by working out what it actually is, then doing the right thing for that kind. The goal is a clear, verified status, not a fix. First, classify the issue Judge by the content, not the label — a "[Feature]" is often really a bug (something already should work), and a "[Bug]" is sometimes expected behaviour. Work out what it actually is: Bug — reproduce it. The bulk of this skill. Feature request — nothing to reproduce. Check it doesn't already exist (search docs/API, maybe under another name), verify any source the reporter cites by reading it, and surface the real design question. If it's small and well-scoped (like "fail loudly instead of silently"), the ideal takeaway is an acceptance test : one self-contained spec asserting current behaviour (passes today) with the desired behaviour alongside as a fixme /commented assertion. Upstream / environment — a genuinely external owner (the Node project, a browser engine, a website's own server/cert config), not Playwright. Find the real owner, don't brute-force a repro, verify any cited upstream issue and point at the real fix path. Note: the Playwright family — @playwright/mcp (source lives here under packages/playwright-core/src/tools/mcp/ ), playwright-vscode , -python , -java , -dotnet — is not "upstream"; it's us. Never tell a reporter to refile within the project (see below). Question / usage — answer it or point at the docs. The rest of this skill is the bug path. Reproducing a bug You're not in a hurry, so be exhaustive before giving up. If the user has provided a minimal repro, try it first. If it does not repro for you, play around with things they might have forgotten to mention: all three browsers, headed/headless, a few recent versions, and variations of the snippet or trigger. Report "cannot reproduce" only after you've genuinely explored — and say what you tried. If you have a hunch for what information would help, ask for it. Run across browsers, and watch for divergence — a bug that only reproduces in webkit, or everywhere except firefox, is a strong signal worth leading with. Plenty of bugs are browser-agnostic, though, and those are just as real: reproducing on every browser is a good result to report, not a non-finding. Read the whole thread , comments included — the missing repro or narrowed trigger is often there. Pull the inputs : version, browser(s), OS, repro repo/snippet, Expected-vs-Actual (your oracle). If something's missing, guess and try anyway; note assumptions in the report. Reproduce on tip-of-tree first , in ~/tmp/issue-<number>/ : clone the linked repo, or scaffold npm install @playwright/test@next with a single-project config (see bisect-published-versions.md ). Use PLAYWRIGHT_HTML_OPEN=never . If it reproduces on ToT, it's a live bug — record the exact version/sha you tested, and if it looks like a regression, bisect it (see the guide). If ToT doesn't reproduce it , try the version the user reported. If it reproduces there but not on ToT, it's already fixed — find the version/PR that fixed it (a cherry-pick may still be worth it). If neither reproduces, it's incomplete or env-specific — say what you couldn't match. (A version ending in -next , e.g. 1.62.0-next , is not an npm version — it means tip-of-tree, which is the @next build you already tried.) To step through a test interactively, use the playwright-cli skill. Reports sometimes target another part of the Playwright project — @playwright/mcp (its source is in this repo), playwright-vscode , playwright-python , playwright-java , playwright-dotnet . These are all us , so triage them like anything else: check out that repo and reproduce there in its own language/toolchain when needed. Never tell the reporter the issue belongs in a different Playwright repo or should be refiled there — that's an internal routing detail, not the reporter's problem. Condense the repro into a self-contained test Big or app-specific repros are much more useful boiled down to a single self-contained spec, written the way our tests are : one test(...) using the page and server fixtures, tagged with the issue link. Crucially: No test.beforeAll / afterAll , no http.createServer , no manual setup/teardown. The fixtures already give you a page and a web server. Use server.setRoute(...) , server.setRedirect(...) , server.PREFIX , server.EMPTY_PAGE instead of standing up your own. Drive the page with page.setContent(...) or page.goto(server.PREFIX + '/...') . Keep only what's needed to trigger the bug, and end on the assertion that fails. Drop it into the repo ( tests/page/ ) and run it with npm run ctest . Mirror real self-contained tests, e.g.: tests/page/page-network-request.spec.ts — should return event source : server.setRoute SSE endpoint, no lifecycle hooks tests/page/selectors-css.spec.ts — should use light DOM structure for child combinator with slotted content : page.setContent with inline shadow DOM ( #37768 ) tests/page/workers.spec.ts — should report worker script as network request after redirect : server fixture with routes/redirects + a browser-gap fixme ( #35678 ) Report Give a status that fits the issue type — for a bug: reproduced / fixed-on-latest / cannot-reproduce / not-a-bug; for a feature request or upstream/env issue: a short verdict (already-possible, valid request, upstream — owned by X) — plus the evidence. For bugs, include the condensed repro and be exhaustive about what you ran — the full matrix of browsers, versions, and variations you tried, not just the one that worked — so the reader can trust the verdict and skip re-checking. Call out any browser-specific divergence. Write it in the Playwright bot voice ( .github/workflows/bot-voice.md , relative to the repo root) — maintainer voice, not AI-speak. Watch out Only run code you trust — skim a linked repo/snippet first; bail and report that in the issue comment if it has postinstall scripts, obfuscated code, or random small libraries. Triage ends at a reproduction and a status; don't jump to a fix.