Publish Sign in

E2E Test

End-to-end testing command that drives the Vercel Agent Browser CLI through every user journey, taking screenshots, validating UI/UX and…

You say
Install this skill Read the source first Free Written by coleam00 · unverified publisher
Context cost
2.7k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 10.7 kBtext throughout, nothing executable
Licence
free to use
Last change
—no release on file
Servers it uses
Noneruns standalone

What it does

Comprehensive end-to-end testing command. Launches parallel sub-agents to research the codebase (structure, database schema, potential bugs), then uses the Vercel Agent Browser CLI to test every user journey — taking screenshots, validating UI/UX, and querying the database to verify records. Run after implementation to validate everything before code review.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

e2eagent-browserscreenshotstesting
Filed under

Browser Automation

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md10.7 kB · 239 lines
--- name: e2e-test description: Comprehensive end-to-end testing command. Launches parallel sub-agents to research the codebase (structure, database schema, potential bugs), then uses the Vercel Agent Browser CLI to test every user journey — taking screenshots, validating UI/UX, and querying the database to verify records. Run after implementation to validate everything before code review. disable-model-invocation: true ---
7# End-to-End Application Testing
8
9## Pre-flight Check
10
11### 1. Platform Check
12
13agent-browser requires **Linux, WSL, or macOS**. Check the platform:
14```bash
15uname -s
16```
17- Linux or Darwin → proceed
18- Anything else (e.g., MINGW, CYGWIN, or native Windows) → stop with:
19
20> "agent-browser only supports Linux, WSL, and macOS. It cannot run on native Windows. Please run this command from WSL or a Linux/macOS environment."
21
22Stop execution if the platform is unsupported.
23
24### 2. Frontend Check
25
26Verify the application has a browser-accessible frontend. Check for:
27- A package.json with a dev/start script serving a UI
28- Frontend framework files (pages/, app/, src/components/, index.html, etc.)
29- Web server configuration
30
31If no frontend is detected:
32> "This application doesn't appear to have a browser-accessible frontend. E2E browser testing requires a UI to visit. For backend-only or API testing, a different approach is needed."
33
34Stop execution if no frontend is found.
35
36### 3. agent-browser Installation
37
38Check if agent-browser is installed:
39```bash
40agent-browser --version
41```
42
43If the command is not found, install it automatically:
44```bash
45npm install -g agent-browser
46```
47
48After installation (or if it was already installed), ensure the browser engine is set up:
49```bash
50agent-browser install --with-deps
51```
52
53The --with-deps flag installs system-level Chromium dependencies on Linux/WSL. On macOS it is harmless.
54
55Verify installation succeeded:
56```bash
57agent-browser --version
58```
59
60If installation fails, stop with:
61> "Failed to install agent-browser. Please install it manually with npm install -g agent-browser && agent-browser install --with-deps, then re-run this command."
62
63## Phase 1: Parallel Research
64
65Launch **three sub-agents simultaneously** using the Task tool. All three run in parallel.
66
67### Sub-agent 1: Application Structure & User Journeys
68
69> Research this codebase thoroughly. Return a structured summary covering:
70>
71> 1. **How to start the application** — exact commands to install dependencies and run the dev server, including the URL and port it serves on
72> 2. **Authentication/login** — if the app has protected routes, how to create a test account or log in (credentials from .env.example, seed data, or sign-up flow)
73> 3. **Every user-facing route/page** — each URL path and what it renders
74> 4. **Every user journey** — complete flows a user can take (e.g., "sign up → create profile → view public page"). For each journey, list the specific steps, interactions (clicks, form fills, navigation), and expected outcomes
75> 5. **Key UI components** — forms, modals, dropdowns, pickers, toggles, and other interactive elements that need testing
76>
77> Be exhaustive. Testing will only cover what you identify here.
78
79### Sub-agent 2: Database Schema & Data Flows
80
81> Research this codebase's database layer. Read .env.example to understand environment variables for database connections. DO NOT read .env directly. Return a structured summary covering:
82>
83> 1. **Database type and connection** — what database is used (Postgres, MySQL, SQLite, etc.) and the environment variable name for the connection string (from .env.example)
84> 2. **Full schema** — every table, its columns, types, and relationships
85> 3. **Data flows per user action** — for each user-facing action (form submit, button click, etc.), document exactly what records are created, updated, or deleted and in which tables
86> 4. **Validation queries** — for each data flow, provide the exact query to verify records are correct after the action
87
88### Sub-agent 3: Bug Hunting
89
90> Analyze this codebase for potential bugs, issues, and code quality problems. Focus on:
91>
92> 1. **Logic errors** — incorrect conditionals, off-by-one errors, missing null checks, race conditions
93> 2. **UI/UX issues** — missing error handling in forms, no loading states, broken responsive layouts, accessibility problems
94> 3. **Data integrity risks** — missing validation, potential orphaned records, incorrect cascade behavior
95> 4. **Security concerns** — SQL injection, XSS, missing auth checks, exposed secrets
96>
97> Return a prioritized list with file paths and line numbers.
98
99**Wait for all three sub-agents to complete before proceeding.**
100
101## Phase 2: Start the Application
102
103Using Sub-agent 1's startup instructions:
104
1051. Install dependencies if needed
1062. Start the dev server **in the background** (e.g., npm run dev &)
1073. Wait for the server to be ready
1084. Open the app with agent-browser open <url> and confirm it loads
1095. Take an initial screenshot: agent-browser screenshot e2e-screenshots/00-initial-load.png
110
111## Phase 3: Create Task List
112
113Using the user journeys from Sub-agent 1 and findings from Sub-agent 3, create a task (using TaskCreate) for each user journey. Each task should include:
114
115- **subject:** The journey name (e.g., "Test profile creation flow")
116- **description:** Steps to execute, expected outcomes, database records to verify, and any related bug findings from Sub-agent 3
117- **activeForm:** Present continuous (e.g., "Testing profile creation flow")
118
119Also create a final task: "Responsive testing across viewports."
120
121## Phase 4: User Journey Testing
122
123For each task, mark it in_progress with TaskUpdate and execute the following.
124
125### 4a. Browser Testing
126
127Use the Vercel Agent Browser CLI for all browser interaction:
128
129```
130agent-browser open <url> # Navigate to a page
131agent-browser snapshot -i # Get interactive elements with refs (@e1, @e2...)
132agent-browser click @eN # Click element by ref
133agent-browser fill @eN "text" # Clear field and type
134agent-browser select @eN "option" # Select dropdown option
135agent-browser press Enter # Press a key
136agent-browser screenshot <path> # Save screenshot
137agent-browser screenshot --annotate # Screenshot with numbered element labels
138agent-browser set viewport W H # Set viewport (e.g., 375 812 for mobile)
139agent-browser wait --load networkidle # Wait for page to settle
140agent-browser console # Check for JS errors
141agent-browser errors # Check for uncaught exceptions
142agent-browser get text @eN # Get element text
143agent-browser get url # Get current URL
144agent-browser close # End session
145```
146
147**Refs become invalid after navigation or DOM changes.** Always re-snapshot after page navigation, form submissions, or dynamic content updates (modals, tabs, theme changes).
148
149For each step in a user journey:
150
1511. Snapshot to get current refs
1522. Perform the interaction
1533. Wait for the page to settle
1544. **Take a screenshot** — save to a descriptive path under e2e-screenshots/ organized by journey (e.g., e2e-screenshots/profile-creation/03-form-submitted.png)
1555. **Analyze the screenshot** — use the Read tool to view the screenshot image. Check for visual correctness, UX issues, broken layouts, missing content, error states
1566. Check agent-browser console and agent-browser errors periodically for JavaScript issues
157
158Be thorough. Go through EVERY interaction, EVERY form field, EVERY button. The goal is that by the time this finishes, every part of the UI has been exercised and screenshotted.
159
160### 4b. Database Validation
161
162After any interaction that should modify data (form submits, deletions, updates):
163
1641. Query the database to verify records. Use the environment variable from Sub-agent 2's research for the connection string and the schema docs to know what to check.
165 - **Postgres:** use psql directly — e.g., psql "$DATABASE_URL" -c "SELECT theme FROM profiles WHERE username = 'testuser'"
166 - **SQLite:** use sqlite3 directly — e.g., sqlite3 db.sqlite "SELECT theme FROM profiles WHERE username = 'testuser'"
167 - **Other databases:** write a small ad hoc script in the application's language, run it, then delete it
1682. Verify:
169 - Records created/updated/deleted as expected
170 - Values match what was entered in the UI
171 - Relationships between records are correct
172 - No orphaned or duplicate records
173
174### 4c. Issue Handling
175
176When an issue is found (UI bug, database mismatch, JS error):
177
1781. **Document it:** what was expected vs what happened, screenshot path, relevant DB query results
1792. **Fix the code** — make the correction directly
1803. **Re-run the failing step** to verify the fix worked
1814. **Take a new screenshot** confirming the fix
182
183### 4d. Responsive Testing
184
185For the responsive testing task, revisit key pages at these viewports:
186
187- **Mobile:** agent-browser set viewport 375 812
188- **Tablet:** agent-browser set viewport 768 1024
189- **Desktop:** agent-browser set viewport 1440 900
190
191At each viewport, screenshot every major page. Analyze for layout issues, overflow, broken alignment, and touch target sizes on mobile.
192
193After completing each journey, mark its task as completed with TaskUpdate.
194
195## Phase 5: Cleanup
196
197After all testing is complete:
1981. Stop the dev server background process
1992. Close the browser session: agent-browser close
200
201## Phase 6: Report
202
203### Text Summary (always output)
204
205Present a concise summary:
206
207```
208## E2E Testing Complete
209
210**Journeys Tested:** [count]
211**Screenshots Captured:** [count]
212**Issues Found:** [count] ([count] fixed, [count] remaining)
213
214### Issues Fixed During Testing
215- [Description] — [file:line]
216
217### Remaining Issues
218- [Description] — [severity: high/medium/low] — [file:line]
219
220### Bug Hunt Findings (from code analysis)
221- [Description] — [severity] — [file:line]
222
223### Screenshots
224All saved to: e2e-screenshots/
225```
226
227### Markdown Export (ask first)
228
229After the text summary, ask the user:
230
231> "Would you like me to export the full testing report to a markdown file? It includes per-journey breakdowns, all screenshot references, database validation results, and detailed findings — useful as context for follow-up fixes or GitHub issues."
232
233If yes, write a detailed report to e2e-test-report.md in the project root containing:
234- Full summary with stats
235- Per-journey breakdown: steps taken, screenshots, database checks, issues found
236- All issues with full details, fix status, and file references
237- Bug hunt findings from the code analysis sub-agent
238- Recommendations for any unresolved issues
239
In the file
SKILL.md1,562 words
Files1
Licence
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈110
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
2,565
on trigger
The instruction body, read only when the skill fires.
1.3%
of a 200k window
Ten skills this size would take about 13% of the window before you open a file.
050k100k150k200k context window

2.7k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 10.7 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md10.7 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

# E2E Test · 2.7k tokens when loaded npx mcprush@latest skill add coleam00/e2e-test

Writes to .claude/skills/e2e-test/ in the current project. Add --global to put it in your home directory instead, for every project.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
PriceFree
Referencecoleam00/e2e-test

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

—no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Who wrote it

CO
coleam00

Publishes on mcprush.

0 servers listed1 skill listednot claimed
Profile
Publisher
Servers0
Claim this skill