Skip to content
cccskills
FreePublished on GitHub

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

The English summary is being prepared. Showing the original description.

AI-Builder-Club/skills
See how to install

Files included (1)

  • SKILL.md3.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

agent-context-audit

Free

Audit a repo's agent context — CLAUDE.md files, codebase docs, skills, and tool/MCP designs — against Anthropic's Claude 5 context-engineering guidance ("unhobbling": Anthropic cut ~80% of Claude Code's system prompt with no eval loss). Finds overconstraint, conflicting instructions, redundancy, stale facts, and missing "unknown knowns"; produces a scored findings report with concrete rewrites, then applies approved fixes. Use when someone says "audit my CLAUDE.md", "context audit", "unhobble this repo", "review our agent docs/skills/tools", or after upgrading to Claude 5-generation models.

The English summary is being prepared. Showing the original description.

AI-Builder-Club/skills1.3KUpdated Sep 16, 2026

crabbox-setup

Free

Scaffold an isolated CLOUD dev box per agent (via crabbox + Daytona) for any codebase — the parallel-safe counterpart to dev-local-setup. Each agent gets its own full stack (own DB + dev server) and an in-box browser for e2e, so concurrent loops never collide on ports/state. Sets up the snapshot image, .crabbox.yaml, an idempotent setup.sh (also boots the stack locally), and a cbx.sh wrapper. Use when the user says "set up crabbox", "give each agent its own box", "add cloud testing", "make this repo testable in the cloud / on Daytona", "parallel-test this", or when setup-codebase-harness needs true per-agent isolation.

The English summary is being prepared. Showing the original description.

AI-Builder-Club/skills1.3KUpdated Sep 16, 2026

dev-local-setup

Free

Scaffold a one-command `dev-local` launcher for ANY codebase. Investigates the repo to find its services, ports, and infra dependencies, then generates a single `scripts/dev-local.sh` (up/down/status/logs/restart) that runs every dev server in one tmux session, plus a short skill doc describing it. Use when someone says "set up dev-local", "make a one-command dev launcher", "I want one script to start this repo", "scaffold dev-local for this project".

The English summary is being prepared. Showing the original description.

AI-Builder-Club/skills1.3KUpdated Sep 16, 2026

karaoke-captions

Free

Generate TikTok/Shorts-style karaoke captions using MLX Whisper, ASS subtitles, and FFmpeg libass. Use when burning word-level highlight captions into a video, matching caption style from a screenshot, rendering ASS karaoke subtitles, or when the user runs /karaoke-captions.

The English summary is being prepared. Showing the original description.

AI-Builder-Club/skills1.3KUpdated Sep 16, 2026

new-loop

Free

Spin up a new loop (domain) in a file-based knowledge base — bootstrap the substrate if it's missing, gather the loop's charter, scaffold domains/<loop>/README.md, then do ONE real test run and record it in the loop's Timeline and LOG.md. Use when the user says "set up a new loop", "create a domain", "start a new beat/workstream", or names a recurring job they want the agent to own.

The English summary is being prepared. Showing the original description.

AI-Builder-Club/skills1.3KUpdated Sep 16, 2026

open-agent-teams

Free

Delegate tasks to ANY CLI agent (claude, codex, aider, ...) running in a detached tmux session, with a race-safe done-signal protocol and multi-turn iteration. Use when delegating work to a non-Claude CLI agent, when the user says "tmux delegate", "run agent in tmux", "delegate to codex/aider", or when executor work should run in an observable background terminal instead of the Agent tool.

The English summary is being prepared. Showing the original description.

AI-Builder-Club/skills1.3KUpdated Sep 16, 2026

See all skills by AI-Builder-Club

Report a problem with this skill