Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
alirezarezvani avatar

Fix

  • 1.6k installs
  • 23.5k repo stars
  • Updated July 17, 2026
  • alirezarezvani/claude-skills

A systematic four-step process that categorizes flaky Playwright tests into root cause buckets (Timing/Async, Test Isolation, Environment, Infrastructure) and applies targeted remediation with verification.

About

This skill provides a structured approach to diagnosing and fixing failing or flaky Playwright tests. It uses a four-category taxonomy: Timing/Async, Test Isolation, Environment, and Infrastructure. The workflow reproduces failures through progressive test runs, captures execution traces, categorizes root causes, applies targeted fixes, and verifies stability across ten consecutive runs. Developers systematize test troubleshooting by running burn-in tests, analyzing traces, isolating failure patterns between CI and local environments, and implementing prevention measures like retry configuration and trace collection.

  • Four-category flaky test taxonomy: Timing/Async, Test Isolation, Environment, Infrastructure
  • Systematic reproduction via burn-in (--repeat-each=10) and parallel worker testing
  • Trace-based diagnosis with targeted fixes per failure category
  • Verification through 10 consecutive passes before declaring stability
  • Prevention via CI retries, trace collection, and test conventions documentation

Fix by the numbers

  • 1,622 all-time installs (skills.sh)
  • +1 installs in the week ending Jul 29, 2026 (Skillselion tracking)
  • Ranked #455 of 2,159 Testing & QA skills by installs in the Skillselion catalog
  • Security screen: LOW risk (skills.sh audit)
  • Data as of Jul 31, 2026 (Skillselion catalog sync)
npx skills add https://github.com/alirezarezvani/claude-skills --skill fix

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1.6k
repo stars23.5k
Security audit3 / 3 scanners passed
Last updatedJuly 17, 2026
Repositoryalirezarezvani/claude-skills

What it does

Diagnose and fix failing or flaky Playwright tests using systematic categorization and targeted remediation.

Who is it for?

Software engineers debugging Playwright test failures, DevOps improving CI reliability, QA engineers ensuring test suite stability.

Skip if: Unit test frameworks other than Playwright; performance testing; load testing; static analysis.

When should I use this skill?

User reports failing test, flaky test, intermittent failure, test passes locally but fails in CI, or test passes sometimes.

What you get

Tests pass consistently across 10 consecutive runs; CI reliability improves; developers prevent flakiness through documented conventions.

  • Flaky root-cause diagnosis
  • Stabilized test assertions
  • Per-test isolation fixes

By the numbers

  • Decision tree uses --repeat-each=20 for local flaky reproduction checks

Files

SKILL.mdMarkdownGitHub ↗

Fix Failing or Flaky Tests

Diagnose and fix a Playwright test that fails or passes intermittently using a systematic taxonomy.

Input

$ARGUMENTS contains:

  • A test file path: e2e/login.spec.ts
  • A test name: ""should redirect after login"`
  • A description: "the checkout test fails in CI but passes locally"

Steps

1. Reproduce the Failure

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

2. Capture Trace

Run with full tracing:

npx playwright test <file> --trace=on --retries=0

Read the trace output. Use /debug to analyze trace files if available.

3. Categorize the Failure

Load flaky-taxonomy.md from this skill directory.

Every failing test falls into one of four categories:

CategorySymptomDiagnosis
Timing/AsyncFails intermittently everywhere--repeat-each=20 reproduces locally
Test IsolationFails in suite, passes alone--workers=1 --grep "test name" passes
EnvironmentFails in CI, passes locallyCompare CI vs local screenshots/traces
InfrastructureRandom, no patternError references browser internals

4. Apply Targeted Fix

Timing/Async:

  • Replace waitForTimeout() with web-first assertions
  • Add await to missing Playwright calls
  • Wait for specific network responses before asserting
  • Use toBeVisible() before interacting with elements

Test Isolation:

  • Remove shared mutable state between tests
  • Create test data per-test via API or fixtures
  • Use unique identifiers (timestamps, random strings) for test data
  • Check for database state leaks

Environment:

  • Match viewport sizes between local and CI
  • Account for font rendering differences in screenshots
  • Use docker locally to match CI environment
  • Check for timezone-dependent assertions

Infrastructure:

  • Increase timeout for slow CI runners
  • Add retries in CI config (retries: 2)
  • Check for browser OOM (reduce parallel workers)
  • Ensure browser dependencies are installed

5. Verify the Fix

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.

6. Prevent Recurrence

Suggest:

  • Add to CI with retries: 2 if not already
  • Enable trace: 'on-first-retry' in config
  • Add the fix pattern to project's test conventions doc

Output

  • Root cause category and specific issue
  • The fix applied (with diff)
  • Verification result (10/10 passes)
  • Prevention recommendation

Related skills

How it compares

Choose fix over generic testing tips when you need a structured Playwright/Cypress flaky taxonomy instead of ad hoc wait increases.

FAQ

How do I know if a test is flaky vs consistently failing?

Run npx playwright test <file> --repeat-each=10 --reporter=list. If it fails consistently on first run, it's a bug. If it passes sometimes, categorize via taxonomy: does it fail everywhere (Timing/Async), only in suite (Isolation), only in CI (Environment), or randomly (Infrastru

What's the difference between Timing/Async and Test Isolation failures?

Timing/Async fails everywhere intermittently due to race conditions or missing waits. Test Isolation fails only when tests run together (shared state pollution). Check: does --repeat-each=20 locally reproduce it (Timing), or does --workers=1 --grep make it pass (Isolation)?

Why should I enable trace collection in CI?

Traces capture DOM snapshots, network logs, and screenshots at failure moment. Use trace: 'on-first-retry' in config to collect traces only on retry, reducing overhead. Analyze with Playwright Inspector (/debug) to see exact element state and timing when failure occurred.

Is Fix safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

Testing & QAtestingdevops

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.