Menu
E2E/QA testing with agent-browser CLI for token-efficient browser automation
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| 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.