MCPInstall

e2e

Use when running e2e tests, debugging test failures, or fixing flaky tests. Covers failure taxonomy, fix rules, and workflow. Never changes source code logic or API without spec backing.

Installs
194
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/alleneubank/claude-code --skill e2e
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads e2e automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

E2E Testing

Failure Taxonomy

Every e2e failure is exactly one of:

A. Flaky (test infrastructure issue)

  • Race conditions, timing-dependent assertions, stale selectors, missing waits
  • Symptom: passes on retry, fails intermittently

B. Outdated (test no longer matches implementation)

  • Test asserts old behavior that was intentionally changed; selectors reference removed elements
  • Symptom: consistent failure, app works correctly

C. Bug (implementation doesn't match spec)

  • Test correctly asserts spec'd behavior, code is wrong
  • Only classify as bug when a spec exists to validate against
  • If no spec exists, classify as "unverified failure" and report to the user

Fix Rules by Category

Flaky fixes:

  • Replace waitForTimeout with auto-waiting locators
  • Replace brittle CSS selectors with getByRole/getByLabel/getByTestId
  • Fix race conditions with expect() web-first assertions
  • Fix mock/route setup ordering (before navigation)
  • Never add arbitrary delays - fix the underlying wait
  • Never add retry loops around assertions - use the framework's built-in retry

Outdated fixes:

  • Update test assertions to match current (correct) behavior
  • Update selectors to match current DOM/API
  • Never change source code - the implementation is correct, the test is stale

Bug fixes:

  • Quote the spec section that defines expected behavior
  • Fix the source code to match the spec
  • Unit tests MUST exist before the fix is complete — write them first if missing (TDD)
  • Never change e2e assertions to match buggy code
  • Never change API contracts or interfaces without spec backing
  • If no spec exists, ask the user: bug or outdated test?

Source Code Boundary

E2e test fixes must not change application logic, API contracts, database schemas, or configuration defaults. The only exception: bug fixes where a spec explicitly defines the correct behavior and unit tests cover the fix.

Workflow

Step 1: Discover Test Infrastructure

  1. Find e2e config: playwright.config.ts, vitest.config.ts, or project-specific setup
  2. Read package.json for the canonical e2e command
  3. Check if dev server or Tilt environment is required and running
  4. Find spec files: *.spec.md, docs/*.spec.md - source of truth for bug decisions

Step 2: Run Tests

# Playwright
yarn playwright test --reporter=line

# Or project-specific
yarn test:e2e

Parse failures into:

TestFileErrorCategory
login flowauth.spec.ts:42timeout waiting for selectorTBD

Step 3: Categorize

For each failure: read the test file, read the source code it exercises, check for a corresponding spec file, assign category (flaky / outdated / bug / unverified).

Step 4: Fix by Category

Apply fixes in order: flaky first (unblocks other tests), then outdated, then bug.

Step 5: Re-run and Report

## E2E Results

**Run**: `yarn test:e2e` on <date>
**Result**: X/Y passed

### Fixed
- FLAKY: `auth.spec.ts:42` - replaced waitForTimeout with getByRole wait
- OUTDATED: `profile.spec.ts:88` - updated selector after header redesign
- BUG: `transfer.spec.ts:120` - fixed amount validation per SPEC.md#transfers

### Remaining Failures
- UNVERIFIED: `settings.spec.ts:55` - no spec, needs user decision

### Unit Tests Added
- `src/transfer.test.ts` - amount validation edge cases (covers BUG fix)

See testing-best-practices for async handling, flake classification, and preflight check patterns.

FAQ

What does the e2e skill do?

Use when running e2e tests, debugging test failures, or fixing flaky tests. Covers failure taxonomy, fix rules, and workflow. Never changes source code logic or API without spec backing.

How do I install e2e?

Run npx skills add https://github.com/alleneubank/claude-code --skill e2e in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/e2e/ (personal) or .claude/skills/e2e/ (project).

Which AI agents can use e2e?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is e2e safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains e2e?

It is published by alleneubank in alleneubank/claude-code. It has 194 recorded installs.

More from alleneubank/claude-code

View all →

typescript-best-practices

alleneubank/claude-code

Use when reading or writing TypeScript or JavaScript files (.ts, .tsx, .js, tsconfig.json).

react-best-practices

alleneubank/claude-code

Use when reading or writing React components (.tsx, .jsx files with React imports).

Frontend & Design3.2K installs

python-best-practices

alleneubank/claude-code

Use when reading or writing Python files (.py, pyproject.toml, requirements.txt).

web-fetch

alleneubank/claude-code

Fetches web content as clean markdown by preferring markdown-native responses and falling back to selector-based HTML extraction. Use for documentation, articles, and reference pages at http/https URLs.

Docs & Writing978 installs

nix-best-practices

alleneubank/claude-code

Use when working with Nix flakes, overlays, shell.nix, or flake.nix files.

zig-best-practices

alleneubank/claude-code

Use when reading or writing Zig files (.zig, build.zig, build.zig.zon).

Popular testing & qa skills

View category →

tdd

mattpocock/skills

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Testing & QA1.2M installs

grilling

mattpocock/skills

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

Testing & QA996.2K installs

migrate-to-shoehorn

mattpocock/skills

Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.

Testing & QA484.1K installs

run-train

lllllllama/rigorpilot-skills

Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.

Testing & QA337.8K installs

test-driven-development

obra/superpowers

Use when implementing any feature or bugfix, before writing implementation code

Testing & QA261.8K installs

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

Testing & QA216.8K installs