Menu
E2E/QA testing with agent-browser CLI for token-efficient browser automation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | e2e-testing |
| description | E2E/QA testing with agent-browser CLI for token-efficient browser automation |
| triggers | ["e2e test","e2e 테스트","browser test","브라우저 테스트","qa test","qa 테스트","페이지 테스트","화면 테스트","agent-browser","end to end"] |
Browser automation for QA/E2E testing using Vercel's agent-browser CLI.
Uses accessibility tree refs (@e1, @e2) instead of CSS selectors — 5.7x more token-efficient than Playwright MCP.
npm install -g agent-browser
agent-browser install # installs Chromium
1. Open & Snapshot (understand the page)
agent-browser open <URL> && agent-browser wait --load networkidle && agent-browser snapshot -i
snapshot -i returns interactive elements only (buttons, inputs, links) with refs like @e1, @e22. Interact (fill forms, click buttons)
agent-browser fill @e3 "test@example.com"
agent-browser fill @e4 "password123"
agent-browser click @e5 # Submit button
agent-browser wait --load networkidle
3. Assert (verify results)
agent-browser snapshot -i # Check new page state
agent-browser get text @e10 # Get specific element text
agent-browser get url # Check current URL
agent-browser screenshot result.png # Visual evidence
4. Chain Commands (single bash call)
agent-browser open localhost:3000 && \
agent-browser wait --load networkidle && \
agent-browser snapshot -i
| Command | Description |
|---|---|
open <url> | Navigate to URL |
snapshot | Full accessibility tree with refs |
snapshot -i | Interactive elements only (less tokens) |
click @ref | Click element by ref |
fill @ref "text" | Clear and fill input |
type @ref "text" | Type into element (append) |
press Enter | Press keyboard key |
select @ref "value" | Select dropdown option |
check @ref / uncheck @ref | Checkbox toggle |
scroll down 500 | Scroll direction + pixels |
wait @ref | Wait for element to appear |
wait 2000 | Wait milliseconds |
wait --load networkidle | Wait for network idle |
get text @ref | Get element text content |
get url | Get current page URL |
get value @ref | Get input value |
screenshot [path] | Take screenshot |
screenshot --full | Full page screenshot |
screenshot --annotate | Labeled screenshot for AI review |
eval "js code" | Execute JavaScript |
close | Close browser |
@e1 # Ref from snapshot (preferred)
"button:has-text('Submit')" # CSS + text selector
"#email" # CSS ID selector
".btn-primary" # CSS class selector
Auth Flow Test:
agent-browser open localhost:3000/auth && agent-browser wait --load networkidle && agent-browser snapshot -i
# Read refs → find email input (@e3), password input (@e4), login button (@e5)
agent-browser fill @e3 "test@example.com" && agent-browser fill @e4 "password123" && agent-browser click @e5
agent-browser wait --load networkidle && agent-browser get url
# Assert: URL should be / (home page) after successful login
Product Listing Test:
agent-browser open localhost:3000/products && agent-browser wait --load networkidle
agent-browser snapshot -i
# Assert: product cards visible, filter sidebar present
agent-browser screenshot products-page.png
Checkout Flow Test:
# 1. Add to cart
agent-browser open localhost:3000/products/some-id && agent-browser wait --load networkidle
agent-browser snapshot -i
# Select size, click Add to Cart
agent-browser click @e8 # size button
agent-browser click @e12 # add to cart
# 2. Go to cart
agent-browser open localhost:3000/cart && agent-browser wait --load networkidle
agent-browser snapshot -i
# 3. Checkout
agent-browser click @e5 # proceed to checkout
agent-browser wait --load networkidle
agent-browser snapshot -i
# Fill shipping form, submit
After each test, create a structured result:
## Test: [Name]
- URL: [tested URL]
- Status: PASS / FAIL
- Steps:
1. [action] → [expected] → [actual]
2. ...
- Screenshot: [path if captured]
- Errors: [any errors encountered]
snapshot -i vs full snapshot:
snapshot -i shows only interactive elements (buttons, links, inputs) — great for form filling and clickingsnapshot shows ALL content including text, headings, paragraphs — use when verifying page content, brand descriptions, product detailssnapshot -i shows the same elements after navigation, the URL may have changed but text content differs — use full snapshot or get url to verifyZustand/localStorage verification:
agent-browser eval "localStorage.getItem('auth-storage')"
agent-browser eval "JSON.parse(localStorage.getItem('key')).state.field"
SPA hydration awareness:
agent-browser open (full page load), zustand persist stores need ~100-500ms to rehydrate from localStorageagent-browser wait 1000 or agent-browser wait 2000 after navigation before checking auth-dependent stateopen command does full page loadForm submission debugging:
snapshot for error messages, (2) auth state, (3) console errors via evalagent-browser eval "document.querySelector('[role=alert]')?.textContent" to find error alertssnapshot -i (interactive only) instead of full snapshot — 60-80% less tokens&& in a single bash call — one tool call instead of manyget text are cheaperagent-browser close@e1) — never re-snapshot just to get CSS selectorseval for state checks — cheaper than re-snapshotting to verify JS stateTypical test URLs for a 4-service e-commerce platform:
http://localhost:3000http://localhost:8081http://localhost:8082http://localhost:8083http://localhost:8084Start services before testing:
# Terminal 1: Backend (from repo root)
cd backend-v2 && ./gradlew bootRun
# Terminal 2: Frontend
cd frontend && npm run dev
# Terminal 3: Tests (or use agent-browser directly)
agent-browser open http://localhost:3000
agent-browser --headless open <url> && agent-browser snapshot -i
# Save login state
agent-browser --session-name ecommerce open localhost:3000/auth
# Login manually or via commands
# Next time, session is restored:
agent-browser --session-name ecommerce open localhost:3000
Scaffold a new domain feature with TDD order (entity -> test -> service -> test -> controller -> test)
새 Spring Boot 멀티모듈 프로젝트의 기초 세팅(common shared kernel + Gradle/Docker/CI 골격)을 깔아주는 스킬. 시스템 설계 문서 기반 구현 시작 시 가장 먼저 발동. 핵심 골격만 포함 — `BusinessException`/`ErrorCodeBase`/`ApiResponse`/`GlobalExceptionHandler`/`BaseEntity` + JPA/CORS/OpenAPI configs. Kafka/Outbox/QueryDSL 같은 도메인 특화 패턴은 별도 llm-wiki에서 끌어다 쓴다.
Design partner mode for system design practice. Activated when the user wants to design a new system (chat, notification, news feed, URL shortener, etc.). Sets up topic directory, copies the mock-interview template, loads the matching problem from sysdesign-question-bank, marks the topic as active in .omx/state/, and conducts a back-and-forth Clarifying → High Level → Drill Down conversation, updating <topic>/System-Design-Document/mock-interview.md immediately as each decision lands. Uses Alex Xu Vol.1's canned numbers as the starting point (book-first), user adjusts. NOT an interview — the user drives, this skill is a design collaborator with a calculator (back-of- envelope, latency estimation via auto-injected sysdesign-frameworks) and a reference book (sysdesign-question-bank).
Scaffold a minimum-viable implementation of a designed system. Activated when the user is ready to write code. Reads sdd.md (or falls back to mock-interview.md), determines the smallest component subset that lets the design's NFRs be testable (NOT a full production build — single-region, in-memory or single-container infra, no CDN, no multi-region), asks the user for the language/framework stack (default Spring Boot + PostgreSQL + Kafka per project's existing skill set), then scaffolds <topic>/source/ with per-service directories, a docker-compose.yml that brings everything up locally, and test-results/ scaffolding for functional / load / failure tests. The point is verification of design assumptions, not production.
Promote a filled mock-interview.md into a formal Software Design Document (sdd.md) following the IEEE 1016 / Atlassian / Google design-doc style. Activated when the user says they are ready to write the SDD. Reads the topic's mock-interview.md AND the topic's conversation log files (which capture the back-and-forth detail not preserved in the structured mock-interview), then asks the user the SDD-specific questions that mock-interview doesn't cover (Constraints, ADRs, Risk Register, Rollout, Testing strategy). Writes sdd.md incrementally as decisions land.
TDD workflow, per-layer test types, naming conventions, and test fixture patterns for Spring Boot. Use when writing or reviewing tests.