E2e setup

Skill AI-Builder-Club/skills/skills/e2e-setup

Codebase harness + loop engineer

Install

npx -y skills add AI-Builder-Club/skills --skill e2e-setup

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

Set up an end-to-end test suite in any repo, following practices that make e2e a reliable per-PR gate: real flows over bypass, layered assertions, a reusable auth/session helper, video+trace evidence, and a compounding suite. Use when a repo has no e2e (or weak e2e) and you want system-level tests — "set up e2e", "add end-to-end tests", "scaffold a test gate".

SKILL.md

3.8 KB, as published. Nobody here has run it

Set up an e2e test suite

E2e tests verify the whole running system through the app (browser/API), not one module. They are the per-PR gate. Pairs with dev-local-setup (a reproducible local stack) and verifier-setup (which scaffolds the repo's /verify skill — the verify→ship loop this gate feeds into).

Where it lives

Unit/integration tests stay inside each app/package — they own one module.
System e2e is a dedicated top-level package (e.g. e2e/) — it spans all apps, so it belongs to none. Add it to the workspace if a monorepo.

The recipe

Stand the app up reproducibly — see dev-local-setup. The e2e suite never boots the app itself; it runs against the already-running stack. That stack can be local (dev-local-setup) or an isolated cloud box (crabbox-setup) — same specs, run against either. For parallel agents use the cloud box (one laptop can't host concurrent stacks).
Pick the framework that fits (Playwright for browser; your HTTP client for API). Turn on video + trace — the recording is the proof, and it's gitignored output.
Explore the flow live first (don't guess selectors), then crystallize it into a committed spec.
Keep the gate small: a handful of critical journeys, deterministic. Each new feature PR adds its spec — the suite compounds.

Practices that make e2e trustworthy

Real flow, not bypass. Drive the genuine path. For email codes / OTP, read the real code from a local mail server (Mailpit / Inbucket / MailHog) — never hardcode a fixed test code. That's what makes it a test, not a rehearsal.
Verify auth ITSELF once; bypass it everywhere else. A dedicated signup/login spec proves auth works. Every other spec shouldn't re-pay the login tax — build a session helper that mints an authed state once (real flow → saved storage state, or a service-role/token mint) and load it.
Layered assertions: client → server → product. Don't stop at "the UI changed." Confirm the server agrees (token validates / row/state is right) AND the user-visible outcome (e.g. plan upgraded and credits granted).
Stable selectors. Prefer role/label/text; add a small data-testid in the component when there's no good handle — never a brittle CSS path.
Fresh data per run. Unique emails/ids so reruns don't collide; mind rate limits (auth email, etc.).
Commit specs + helpers, never test-results/ (generated output).

When a test fails: triage before "fixing"

A red e2e is information. Classify first:

Real bug — the product broke. Fix the code; the test did its job.
Stale test — the flow intentionally changed (renamed route, new step). Update the test to match the new contract.
Flaky / env — stack down, timing, rate limit, stale data. Fix robustness/env.

Never weaken or delete an assertion just to go green. Loosening is only correct when the intended contract changed — confirmed from the diff, not assumed.

External services (payments, email, 3rd-party)

Use the vendor's test/sandbox mode, never live keys — and guard hard: the test should refuse to run if it detects a live key/credential. If a webhook completes the flow, forward it locally (e.g. the vendor's CLI listener) so the e2e exercises the real fulfilment path, not a faked event.