
E2E
Classify e2e test failures and apply targeted fixes using proven taxonomy
What You Can Do
You can quickly categorize e2e test failures using a proven taxonomy (flaky, outdated, or bug), then apply the correct fix strategy for each category. The skill ensures you never conflate test infrastructure issues with implementation problems, maintains clean boundaries between test and source code, and validates fixes against specifications before modifying application logic.
Features
instantly categorize failures as flaky (timing/selector issues), outdated (test doesn't match current behavior), or bugs (code doesn't match spec)
replace arbitrary delays with auto-waiting locators, fix race conditions with web-first assertions, and correct selector brittleness using semantic queries
update assertions and selectors to match current correct behavior without touching source code
only classify as bugs when spec exists; fix source code with unit tests first, never modify e2e assertions to match buggy code
prevents accidental API contract changes and enforces test/implementation separation
flags failures without specification backing for stakeholder decision-making
quotes relevant specification sections before applying any implementation fixes
Example Output
Example 1: Flaky Failure
Input: Test intermittently fails with element not found on login form
Classification: Flaky — stale selector / race condition
Fix:
// Before: brittle selector + arbitrary delay
await page.waitForTimeout(500);
const button = await page.$('.login-btn');
// After: semantic locator + web-first assertion
const button = page.getByRole('button', { name: /sign in/i });
await expect(button).toBeVisible();
Example 2: Outdated Test
Input: Test fails asserting error message on empty email field
Classification: Outdated — spec changed, email is now optional
Fix: Update test assertion to match current (correct) behavior
// Before: expects error
await expect(page.getByText(/email required/i)).toBeVisible();
// After: reflects new spec (email optional)
await expect(page.getByText(/email required/i)).not.toBeVisible();
Example 3: Bug with Spec
Input: Test consistently fails; payment confirms before processing
Classification: Bug — implementation violates payment spec § 4.2
Fix: Correct source code to match spec, add unit tests first
// Per Spec § 4.2: "confirmation must occur AFTER processing"
// Fix in payment.js, then verify with unit test before e2e
test('payment confirmation waits for processor response', () => { ... });
What's Included
- SKILL.md: complete failure taxonomy and fix rules by category
- Flaky Fixes Checklist: selector strategies, timing patterns, and anti-patterns
- Bug vs. Outdated Decision Tree: flowchart for classification when ambiguous
- Spec Validation Template: format for quoting spec sections before bug fixes
- Source Code Boundary Guardrails: rules preventing test/implementation bleed
Who It's For
- QA Engineers — diagnose and fix e2e test failures systematically without guesswork
- Frontend Developers — apply test fixes that preserve code boundaries and specification integrity
- Test Automation Engineers — maintain flaky test prevention and classification consistency across suites
- Engineering Leads — enforce strict test/implementation separation and spec-driven bug fixes in code review
Best For
- Debugging intermittent e2e test failures and flaky assertions
- Updating tests after intentional feature changes without touching source code
- Validating that bug fixes match specification before implementation
- Preventing accidental API contract changes during e2e debugging
- Classifying ambiguous test failures for stakeholder action







