From bee
Provides browser-level verification using Claude-in-Chrome (primary) or chrome-devtools-mcp (fallback). Includes provider detection, dev server detection, and graceful degradation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/bee:browser-testingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Browser MCP tools give you browser-level verification — navigate pages, read DOM content, check console errors, take screenshots, and interact with UI elements.
Browser MCP tools give you browser-level verification — navigate pages, read DOM content, check console errors, take screenshots, and interact with UI elements.
This skill applies to any agent or command that performs browser-based verification — the browser-verifier agent (dev and test modes) and the browser-test command (standalone regression testing).
Bee supports two browser MCP providers. Try them in order — use whichever is available.
Call tabs_context_mcp (tool: mcp__claude-in-chrome__tabs_context_mcp).
Use ToolSearch with query "+chrome-devtools-mcp" to discover chrome-devtools-mcp tools.
list_pages (tool: mcp__plugin_chrome-devtools-mcp_chrome-devtools__list_pages).
Tell the user:
"Browser verification requires a browser MCP provider. Install one of these:
- Claude-in-Chrome extension — install from Chrome Web Store
- chrome-devtools-mcp plugin — install from the Claude Code plugin marketplace:
claude plugins install chrome-devtools-mcp"
Then degrade based on mode.
Important: Decide the provider ONCE at the start of the session. Do not re-check per operation. Use the chosen provider's tools consistently throughout.
Tools are prefixed with mcp__claude-in-chrome__.
| Tool | What it does | When to use it |
|---|---|---|
tabs_context_mcp | Get info about current browser tabs | Availability check |
tabs_create_mcp | Create a new empty tab | Opening a fresh tab for testing |
navigate | Navigate to a URL | Loading the app at the target URL |
read_page | Get accessibility tree of page elements | Verifying element presence, structure, interactive states |
find | Find elements by natural language description | Locating specific UI elements ("login button", "search bar") |
get_page_text | Extract raw text content from the page | Verifying text content |
computer | Mouse/keyboard interaction and screenshots | Clicking, typing, scrolling, taking screenshots |
javascript_tool | Execute JavaScript in page context | Checking runtime state, custom assertions |
read_console_messages | Read browser console output | Checking for runtime errors, exceptions, warnings |
tabs_context_mcp → check availabilitytabs_create_mcp → open fresh tabnavigate → load the app URLread_page → verify page structurefind / computer → interact with elementsread_page or computer (screenshot) → verify outcomeread_console_messages → check for errorsUse computer with action: "screenshot" to capture the current viewport.
Tools are prefixed with mcp__plugin_chrome-devtools-mcp_chrome-devtools__.
| Tool | What it does | When to use it |
|---|---|---|
list_pages | List available browser pages/tabs | Availability check |
new_page | Open a new browser page | Opening a fresh page for testing |
navigate_page | Navigate to a URL | Loading the app at the target URL |
take_snapshot | Get page structure with element uids (text-based, fast) | Verifying element presence; getting uids for interaction |
take_screenshot | Capture visual screenshot | Visual verification, audit trail |
click | Click an element by uid | Buttons, links, checkboxes |
fill | Fill an input field by uid | Text inputs, textareas |
fill_form | Fill multiple form fields at once | Forms with multiple inputs |
type_text | Type text (keyboard-level) | Typing into focused elements |
press_key | Press a specific key | Enter, Escape, Tab, arrow keys |
hover | Hover over an element by uid | Hover states, tooltips |
select_page | Switch to a different page/tab | Multi-page workflows |
evaluate_script | Execute JavaScript in page context | Runtime state, custom assertions |
list_console_messages | List browser console messages | Runtime errors, exceptions, warnings |
get_console_message | Get details of a specific console message | Inspecting a particular error |
list_network_requests | List network requests | Checking API calls, failed requests |
get_network_request | Get details of a specific request | Inspecting request/response payloads |
wait_for | Wait for a condition (element, text, network idle) | Ensuring page is loaded before interacting |
resize_page | Resize the browser viewport | Testing responsive layouts |
close_page | Close a browser page | Cleanup after testing |
lighthouse_audit | Run a Lighthouse audit | Performance and accessibility checks |
list_pages → check availabilitynew_page → open fresh pagenavigate_page → load the app URLwait_for → ensure content is loadedtake_snapshot → get element uidsclick / fill / press_key → interact using uids from snapshottake_snapshot or take_screenshot → verify outcomelist_console_messages → check for errorsUse take_screenshot. For large pages, use the filePath parameter to save directly to disk.
Detection follows a priority order. Stop at the first successful detection.
Check these first — developers often document their dev commands:
If context sources don't have the info, analyze the project:
| Ecosystem | Files to check | Common dev commands | Default URL |
|---|---|---|---|
| Node.js / npm | package.json scripts | npm run dev, npm start, next dev, vite | http://localhost:3000 |
| Python | manage.py, pyproject.toml | python manage.py runserver, flask run, uvicorn | http://localhost:8000 |
| Ruby | Gemfile, Procfile | rails server, bundle exec rails s | http://localhost:3000 |
| Go | go.mod, Makefile | go run ., make dev | http://localhost:8080 |
| Rust | Cargo.toml | cargo run, trunk serve | http://localhost:8080 |
| Java | pom.xml, build.gradle | ./mvnw spring-boot:run, ./gradlew bootRun | http://localhost:8080 |
| Elixir | mix.exs | mix phx.server | http://localhost:4000 |
After detection (or if nothing found), always confirm:
"Should I run {detected-command} and test on {default-uri}, or do you want to provide a different starting point URI?"
If nothing was detected, ask directly: "What command starts the dev server, and what URL should I test on?"
bee:sdd)bee:browser-test)Screenshots are stored alongside test reports:
tests/executions/{YYYY-MM-DD}/{specname}-screenshot-{ac-number}.png
Create the directory structure if it doesn't exist.
In the test mode report, reference screenshots by relative path:
- [x] PASS: User can log in with email/password
Screenshot: `user-auth-screenshot-1.png`
- [ ] FAILED: Dashboard shows recent activity
Screenshot: `user-auth-screenshot-2.png`
Expected: Recent activity section visible with at least one entry
Observed: Section not rendered, console error: "TypeError: Cannot read property 'map' of undefined"
npx claudepluginhub incubyte/ai-plugins --plugin beeTests and debugs browser apps using Chrome DevTools MCP to inspect DOM, capture console errors, analyze network requests, profile performance, and verify visuals.
Drives a real browser via Chrome DevTools MCP to debug rendering, console errors, network behavior, performance, and accessibility where static analysis cannot see runtime state.
Automates browser tasks via Chrome DevTools CLI: take snapshots, click, fill, navigate, and more from the terminal.