/test-e2e

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select test-e2e from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv test-e2e, /just-vibe test-e2e and /jv:test-e2e in Claude. See shortcut setup and context examples.

What the agent does

1. Seed controlled data, and define stable setup and cleanup of owned data.
2. Drive user-visible controls with semantic locators through the journey and a failure-recovery path.
3. Assert the final meaningful outcome.

Inputs

• critical journey, environment, test accounts, and external side-effect constraints.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Full user-visible flows including recovery, through real application boundaries available in the test environment.

Writes

Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.

Mode

Apply; critical journey, environment, test accounts, and external side-effect constraints.

Prerequisites

Defined behavior, existing test conventions/runners, isolated fixtures, and relevant dependencies. Requested bounded verification may use owned isolated fixtures without authorizing product edits or live-system tests. Never test destructive behavior against production by default; distinguish mocked behavior from real integration evidence.

Expected output

• End-to-end tests with journey steps, environment, assertions, failure traces and artifacts, and untested external boundaries.

How the work is checked

• A completed UI action has the intended persisted outcome; failed submission preserves recoverable user state.

When to stop or clarify

• Do not send real payments/emails or modify user accounts without explicit scope. Missing integrations are labeled honestly.

Handling missing context

Infer

Read behavior contracts, existing runners and test conventions; distinguish fixture setup failure from a behavioral failure.

Assume

Use the smallest existing local runner and isolated synthetic fixtures that distinguish the requested behavior. When the method needs a library, runner, container runtime or load tool the project lacks, name the exact package or tool, the files it changes and any download, and add it only when the request authorizes new dev dependencies or tools; label a hand-written generator without shrinking, or a fake in place of a real dependency, as such.

Ask

Ask about an unresolved contract that changes the expected result, or the target/load limits before external testing; do not ask the user to choose a runner already configured.

Technical guidance

Evidence

Define the critical user journey, identities, stable state and permitted side effects.

Method

Use semantic locators and user-visible outcomes; isolate accounts and preserve artifacts when the journey fails.

Pitfall

A screenshot or HTTP 200 alone does not prove a completed transaction or accessible interaction.

Check

Run the main path and meaningful recovery path, including direct navigation and persisted result where applicable.

Situational decisions

When a third-party payment or email effect is real: Use an authorized sandbox or controlled boundary; do not send real effects merely to complete a test.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring