engineering-team/playwright-pro/skills/fix/SKILL.md
Fix failing or flaky Playwright tests. Use when user says "fix test", "flaky test", "test failing", "debug test", "test broken", "test passes sometimes", or "intermittent failure".
npx skillsauth add alirezarezvani/claude-skills fixInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Diagnose and fix a Playwright test that fails or passes intermittently using a systematic taxonomy.
$ARGUMENTS contains:
e2e/login.spec.ts"the checkout test fails in CI but passes locally"Run the test to capture the error:
npx playwright test <file> --reporter=list
If the test passes, it's likely flaky. Run burn-in:
npx playwright test <file> --repeat-each=10 --reporter=list
If it still passes, try with parallel workers:
npx playwright test --fully-parallel --workers=4 --repeat-each=5
Run with full tracing:
npx playwright test <file> --trace=on --retries=0
Read the trace output. Use /debug to analyze trace files if available.
Load flaky-taxonomy.md from this skill directory.
Every failing test falls into one of four categories:
| Category | Symptom | Diagnosis |
|---|---|---|
| Timing/Async | Fails intermittently everywhere | --repeat-each=20 reproduces locally |
| Test Isolation | Fails in suite, passes alone | --workers=1 --grep "test name" passes |
| Environment | Fails in CI, passes locally | Compare CI vs local screenshots/traces |
| Infrastructure | Random, no pattern | Error references browser internals |
Timing/Async:
waitForTimeout() with web-first assertionsawait to missing Playwright callstoBeVisible() before interacting with elementsTest Isolation:
Environment:
docker locally to match CI environmentInfrastructure:
retries: 2)Run the test 10 times to confirm stability:
npx playwright test <file> --repeat-each=10 --reporter=list
All 10 must pass. If any fail, go back to step 3.
Suggest:
retries: 2 if not alreadytrace: 'on-first-retry' in configdevelopment
Use when someone wants to run a weekly review, close open loops, audit stalled projects and commitments, get their system back to trusted, restart a lapsed review habit, or says "/cs:weekly-review". Walks David Allen's three-phase loop — GET CLEAR, GET CURRENT, GET CREATIVE — with deterministic scripts that inventory open loops, gate the checklist with named gaps, and score commitment health 0-100.
development
Use when someone wants to decide whether a meeting is worth calling, price a meeting in dollars, build a timeboxed agenda with desired outcomes, or turn messy meeting notes into owned action items — or says "should this be a meeting", "/cs:meeting-prep", or "/cs:meeting-actions". Runs a cost gate (ASYNC / NOT-READY / MEET), builds a decision-first agenda, and extracts an owner + due-date checklist that flags every orphan.
development
Convert a rambling description of a desired outcome into one polished, autonomous /goal prompt ready to paste into a fresh session. Use when the user says "/fable-goal", "turn this into a goal prompt", "write me a fable prompt", "write the prompt that builds X", or rambles about something they want made and asks for the prompt that makes it happen. The output is a single copy-paste prompt, never the build itself. Do NOT use when the user wants the thing built right now in this session — only when they want the PROMPT that will make it happen in a fresh session.
development
Use when someone wants to plan a deep work day, time-block their calendar or task list, budget or cut shallow work, protect focus hours, track deep-work sessions and streaks, run an end-of-day shutdown ritual, or says "/deep-work" or "/time-block". Classifies tasks deep vs shallow, builds an energy-first time-blocked schedule that refuses deep demand past the 4-hour ceiling, batches shallow work into at most two windows, and logs focus sessions against a weekly target.