web-e2e
web-e2e
The orchestration layer for browser e2e against locally running web apps. Three sibling skills already provide the primitives - vd:browser-profile (persistent logged-in Chrome, one deterministic CDP port per profile), agent-browser (drive pages over CDP via snapshot + @e refs), vd:browser-trace (read-only evidence capture on the same port). This skill sequences them per project: is the app up, is the session authenticated, run the flow, judge it with evidence.
Why this composition works: agent-browser joins the stack in connect mode - agent-browser connect <port> attaches over CDP to the browser-profile Chrome, verified live to coexist with the persistent session, the human-shareable window, and a second read-only trace observer on the same port. Its --profile mode is the one to avoid here: that launches a separate Playwright-owned browser with none of those properties. profile-attach.sh is the only sanctioned attach path - it strips AGENT_BROWSER_PROFILE from the environment (a shell-rc export silently redirects "successful" commands to the wrong browser) and verifies navigator.userAgent after connecting, dying on HeadlessChrome.
What this skill is - and isn't
| Skill | Role |
|---|---|
vd:browser-profile |
The session - named persistent profile, login survives across runs |
agent-browser |
The hands - navigate, snapshot, click, fill over CDP (connect mode) |
vd:browser-trace |
The eyes - network/console/screenshot evidence into .o11y/ |
vd:web-e2e (this) |
The playbook - per-project config, readiness, auth state, flows, verdicts |
Alternatives: vd:browser (Browserbase browse CLI) is the remote escalation - cloud sessions with proxies, CAPTCHA solving, and Identity when a local flow hits anti-bot walls. Puppeteer-based chrome-devtools scripts work locally, but their persistence mechanisms don't share a window or port with the human or the tracer.