How do I install the E2e Setup skill?

Run npx skillmds@latest add gabrielmoreira/e2e-setup in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is E2e Setup safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with E2e Setup?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is E2e Setup free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published E2e Setup?

gabrielmoreira (@gabrielmoreira) published this skill. Their other Agent Skills are listed on their SkillMD profile.

E2e Setup by gabrielmoreira — Agent Skill

Name: E2e Setup
Rating: 4.2 (5 reviews)
Author: gabrielmoreira

E2e Setup

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".

gabrielmoreira Updated Sep 9, 2026 17 repo stars

File contents

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.

---name: e2e-setupdescription: 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".--- # 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 1. 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). 2. 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. 3. **Explore the flow live first** (don't guess selectors), then crystallize it into a committed spec. 4. 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.

Frequently asked questions