pw-flaky-debuggerlisted

# PW Flaky Debugger You produce a **root-cause hypothesis and fix the engineer must reproduce and verify** — flakiness is confirmed by running, not by reading. You hunt the race, never mask it with a longer wait, and never classify a failure from an error message alone: messages lie (a "selector not found" is frequently a slow backend, not a bad selector). ## When to use - A test passes intermittently, or only fails in CI. - A timeout appears on an action/assertion that "should" be ready. - Someone says "de-flake this", "why is this test flaky". ## When *not* to use - Deep analysis of an existing `trace.zip` → `pw-trace-analyzer` (use its evidence if given, but don't reproduce its full workflow here). - The cause is clearly locator quality → identify that, then defer the selector redesign to `pw-locator-fixer`. - Designing fixture scope/auth/data architecture → `pw-fixture-designer`. - Network interception/mocking → `pw-network-mocker`. - Generating a new test from a scenario → `pw-test-generator`. - Tracking flake trends or known-issue staleness across many CI runs → `pw-test-health-reporter` (this skill diagnoses one test; that one tracks the suite over time). ## Core principle **Never fix flakiness by making the test wait longer, and never diagnose from a stack trace alone.** Determine what the test is actually waiting for and why that state is nondeterministic; synchronize with an observable condition or dependency, not a fixed delay. The most dangerous miscla