docs(triage): also check previous similar issues and related PRs

[Devin Rousso (dcrousso)]

this will (hopefully) help identifying duplicates and simplify code review

[Yury Semikhatsky (yury-s)]

A few suggestions:

• Search before reproducing, not after. The new sections come after "Condense the repro", so the agent only looks for prior reports once it has already spent its budget (the CI job has a 20 min timeout and a credit cap). A cheap search up front can short-circuit to "duplicate of #N" / "fixed in 1.6x". I'd fold it into the numbered steps right after "Read the whole thread".
• Update the Report section. Statuses are still reproduced / fixed-on-latest / cannot-reproduce / not-a-bug. Add "duplicate of #N" and say where matches go: headline if it's a duplicate, otherwise one line per match in a collapsible. "For each useful match, record the outcome and rationale and explain whether it still applies" will balloon the comment, which is what bot-voice.md tells us to avoid.
• "Check the relevant fix" contradicts "Watch out". The skill ends with "Triage ends at a reproduction and a status; don't jump to a fix", but this section asks for a PR review (masks the symptom? risks other browsers / public API / existing clients?). Scope it to what triage can verify: PR state, whether it shipped and in which version, and whether the condensed repro passes on that branch. The last one is the useful bit and it's missing.
• Give search recipes. In CI gh is forbidden and the agent gets no hint how to search via MCP. Suggest: quote the exact error string, API name + trigger, include closed items, check the issue timeline for cross-references first, and search the family repos (python/java/dotnet/vscode) since duplicates often land there. Cap it at a handful of searches.
• The "avoid contrived tests" paragraph is unrelated to the title and is the most debatable part (a repro poking internal state is still evidence; "how often would real users hit this" is a maintainer call per bot-voice.md). Separate PR?
• Nit: Discussions are disabled on this repo, drop "discussions".

[Pavel Feldman (pavelfeldman)]

Move this to the end, we have too many issues to fill the context with them.

[github-actions]

Test results for "tests 1"

6 flaky

⚠️ [chromium-library] › library/video.spec.ts:762 › screencast › should work with video+trace `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:762 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:436 › should produce network events, routing, and annotations for Service Worker (advanced) `@chromium-ubuntu-22.04-node22`
⚠️ [chromium-library] › library/video.spec.ts:521 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node22`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-ubuntu-22.04-node20`

52079 passed, 1252 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/annotate.spec.ts:446 › should switch screencast to -s session on show --annotate @mcp-windows-latest-firefox

1 flaky

⚠️ [chrome] › mcp/cli-cdp.spec.ts:60 › attach via cdp URL honors PLAYWRIGHT_CLI_SESSION as session name `@mcp-macos-latest-chrome`

8690 passed, 1474 skipped

---

Merge workflow run.

[github-actions]

🟢 The one failure is a known Firefox/Windows flake — this PR is clear

Hi, I'm the Playwright bot and I triaged the red CI here.

[firefox] › mcp/annotate.spec.ts:446 fails only on mcp-windows-latest-firefox, where it has failed 78 of 704 runs (11%) across ~700 distinct SHAs — including main pushes and PRs that have nothing to do with this one. This PR only edits .claude/skills/playwright-triage/SKILL.md, so no product or test code is reachable from the diff.

Details

Pre-existing flake / infra

• [firefox] › mcp/annotate.spec.ts:446 › should switch screencast to -s session on show --annotate (@mcp-windows-latest-firefox) — bimodal on this bot and this bot only: 78 failed / 626 passed. Every other MCP bot is effectively green on the same test (mcp-ubuntu-latest-firefox and mcp-macos-latest-firefox: 0 failures in ~715 runs each), so it isn't a Firefox behaviour difference, it's Windows timing.

  Recent failures on SHAs this PR can't be responsible for: main at 0facd923 (run 35661458547), fix(expect): report target close reason instead of internal protocol error #42861 at fff4b2c8 (run 35749051395), fix(mcp): rebind page-registered WebMCP tools when the tab or frame changes #42821 at 311c7d85 (run 35722584824), fix(clock): make Temporal.Now follow page.clock #42838 at dcdf8cf2 (run 35655715523), plus main at f4244842, ad86e96f, 52a0e720, d1ead3ec, dc0f8522, 77e4a17d, 37f7d8f9.

  Consistent signature — 70 of the 78 failures are the same assertion, the session switch simply never lands:

  expect(locator).toHaveAccessibleName(expected) failed
  Locator:  getByRole('region', { name: /^Session / }).filter({ has: getByRole('option', { selected: true }) })
  Expected: "Session second"
  Received: "Session first"
  Timeout:  30000ms
  

  Last 60 run verdicts on mcp-windows-latest-firefox, oldest first:

  🟩🟩🟩🟩🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟥🟩🟥🟩🟩🟩🟩🟥🟥

Not triaged

The "tests 1" run is fully green (52079 passed) apart from 6 flaky results — library/video.spec.ts:762, :521, library/chromium/chromium.spec.ts:436, and two browsercontext-cookies-third-party.spec.ts cases — all rescued on retry, none reachable from a docs-only diff. The [chrome] › mcp/cli-cdp.spec.ts:60 flake on macOS is the same story.

I'm a first pass, so treat this as a strong signal rather than the final word — but there's no product code in the diff for the failure to hang on.

_{Triaged by the Playwright bot - agent run}