>- 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".
cd ~/.claude/skills
git clone https://github.com/alirezarezvani/claude-skills.git claude-skills mkdir -p ~/.claude/skills/fix
curl -fsSL https://raw.githubusercontent.com/alirezarezvani/claude-skills/HEAD/.gemini/skills/fix/SKILL.md \
-o ~/.claude/skills/fix/SKILL.md 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 configUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when executing implementation plans with independent tasks in the current session
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when implementing any feature or bugfix, before writing implementation code
Use when creating new skills, editing existing skills, or verifying skills work before deployment