
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 fixAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.6k |
|---|---|
| repo stars | ★ 23.5k |
| Security audit | 3 / 3 scanners passed |
| Last updated | July 17, 2026 |
| Repository | alirezarezvani/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
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=listIf the test passes, it's likely flaky. Run burn-in:
npx playwright test <file> --repeat-each=10 --reporter=listIf it still passes, try with parallel workers:
npx playwright test --fully-parallel --workers=4 --repeat-each=52. Capture Trace
Run with full tracing:
npx playwright test <file> --trace=on --retries=0Read 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:
| 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 |
4. Apply Targeted Fix
Timing/Async:
- Replace
waitForTimeout()with web-first assertions - Add
awaitto 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
dockerlocally 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=listAll 10 must pass. If any fail, go back to step 3.
6. Prevent Recurrence
Suggest:
- Add to CI with
retries: 2if 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
Flaky Test Taxonomy
Decision Tree
Test is flaky
│
├── Fails locally with --repeat-each=20?
│ ├── YES → TIMING / ASYNC
│ │ ├── Missing await? → Add await
│ │ ├── waitForTimeout? → Replace with assertion
│ │ ├── Race condition? → Wait for specific event
│ │ └── Animation? → Wait for animation end or disable
│ │
│ └── NO → Continue...
│
├── Passes alone, fails in suite?
│ ├── YES → TEST ISOLATION
│ │ ├── Shared variable? → Make per-test
│ │ ├── Database state? → Reset per-test
│ │ ├── localStorage? → Clear in beforeEach
│ │ └── Cookie leak? → Use isolated contexts
│ │
│ └── NO → Continue...
│
├── Fails in CI, passes locally?
│ ├── YES → ENVIRONMENT
│ │ ├── Viewport? → Set explicit size
│ │ ├── Fonts? → Use Docker locally
│ │ ├── Timezone? → Use UTC everywhere
│ │ └── Network? → Mock external services
│ │
│ └── NO → INFRASTRUCTURE
│ ├── Browser crash? → Reduce workers
│ ├── OOM? → Limit parallel tests
│ ├── DNS? → Add retry config
│ └── File system? → Use unique temp dirsCommon Fixes by Category
Timing / Async
Missing await:
// BAD — race condition
page.goto('/dashboard');
expect(page.getByText('Welcome')).toBeVisible();
// GOOD
await page.goto('/dashboard');
await expect(page.getByText('Welcome')).toBeVisible();Clicking before visible:
// BAD — element may not be ready
await page.getByRole('button', { name: 'Submit' }).click();
// GOOD — ensure visible first
const submitBtn = page.getByRole('button', { name: 'Submit' });
await expect(submitBtn).toBeVisible();
await submitBtn.click();Race with network:
// BAD — data might not be loaded
await page.goto('/users');
await expect(page.getByRole('table')).toBeVisible();
// GOOD — wait for API response
const responsePromise = page.waitForResponse('**/api/users');
await page.goto('/users');
await responsePromise;
await expect(page.getByRole('table')).toBeVisible();Test Isolation
Shared state fix:
// BAD — tests share userId
let userId: string;
test('create', async () => { userId = '123'; });
test('read', async () => { /* uses userId */ });
// GOOD — each test is independent
test('read user', async ({ request }) => {
const response = await request.post('/api/users', { data: { name: 'Test' } });
const { id } = await response.json();
// Use id within this test
});localStorage cleanup:
test.beforeEach(async ({ page }) => {
await page.goto('/');
await page.evaluate(() => localStorage.clear());
});Environment
Explicit viewport:
test.use({ viewport: { width: 1280, height: 720 } });Timezone-safe dates:
// BAD
expect(dateText).toBe('March 5, 2026');
// GOOD — timezone independent
expect(dateText).toMatch(/\d{1,2}\/\d{1,2}\/\d{4}/);Infrastructure
Retry config:
// playwright.config.ts
export default defineConfig({
retries: process.env.CI ? 2 : 0,
workers: process.env.CI ? 2 : undefined,
});Increase timeout for CI:
test.setTimeout(60_000); // 60s for slow CIRelated 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.