Skill
Community

browser-testing

Install
1
Install the plugin
$
npx claudepluginhub incubyte/claude-plugins --plugin bee

Want just this skill?

Then install: npx claudepluginhub u/[userId]/[slug]

Description

This skill should be used when running browser-based verification. Supports two providers: Claude-in-Chrome (primary) and chrome-devtools-mcp (fallback). Contains tool reference, dev server detection, screenshot conventions, and graceful degradation.

Tool Access

This skill uses the workspace's default tool permissions.

Skill Content

Browser Testing

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).


Provider Detection (Do This First)

Bee supports two browser MCP providers. Try them in order — use whichever is available.

Step 1: Try Claude-in-Chrome (primary)

Call tabs_context_mcp (tool: mcp__claude-in-chrome__tabs_context_mcp).

  • If it succeeds → use Claude-in-Chrome for this session. See the Claude-in-Chrome tool table below.
  • If it fails or the tool is not found → continue to Step 2.

Step 2: Try chrome-devtools-mcp (fallback)

Use ToolSearch with query "+chrome-devtools-mcp" to discover chrome-devtools-mcp tools.

  • If tools are found, call list_pages (tool: mcp__plugin_chrome-devtools-mcp_chrome-devtools__list_pages).
    • If it succeeds → use chrome-devtools-mcp for this session. See the chrome-devtools-mcp tool table below.
    • If it fails → plugin is installed but browser is not connected. Tell the user: "chrome-devtools-mcp is installed but the browser is not connected. See https://github.com/nicobailon/chrome-devtools-mcp for setup instructions."
  • If no tools found → no browser MCP available. Degrade based on mode (see Graceful Degradation).

Step 3: No provider available

Tell the user:

"Browser verification requires a browser MCP provider. Install one of these:

  1. Claude-in-Chrome extension — install from Chrome Web Store
  2. 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.


Claude-in-Chrome Tools

Tools are prefixed with mcp__claude-in-chrome__.

ToolWhat it doesWhen to use it
tabs_context_mcpGet info about current browser tabsAvailability check
tabs_create_mcpCreate a new empty tabOpening a fresh tab for testing
navigateNavigate to a URLLoading the app at the target URL
read_pageGet accessibility tree of page elementsVerifying element presence, structure, interactive states
findFind elements by natural language descriptionLocating specific UI elements ("login button", "search bar")
get_page_textExtract raw text content from the pageVerifying text content
computerMouse/keyboard interaction and screenshotsClicking, typing, scrolling, taking screenshots
javascript_toolExecute JavaScript in page contextChecking runtime state, custom assertions
read_console_messagesRead browser console outputChecking for runtime errors, exceptions, warnings

Workflow Pattern (Claude-in-Chrome)

  1. tabs_context_mcp → check availability
  2. tabs_create_mcp → open fresh tab
  3. navigate → load the app URL
  4. read_page → verify page structure
  5. find / computer → interact with elements
  6. read_page or computer (screenshot) → verify outcome
  7. read_console_messages → check for errors

Screenshots (Claude-in-Chrome)

Use computer with action: "screenshot" to capture the current viewport.


chrome-devtools-mcp Tools

Tools are prefixed with mcp__plugin_chrome-devtools-mcp_chrome-devtools__.

ToolWhat it doesWhen to use it
list_pagesList available browser pages/tabsAvailability check
new_pageOpen a new browser pageOpening a fresh page for testing
navigate_pageNavigate to a URLLoading the app at the target URL
take_snapshotGet page structure with element uids (text-based, fast)Verifying element presence; getting uids for interaction
take_screenshotCapture visual screenshotVisual verification, audit trail
clickClick an element by uidButtons, links, checkboxes
fillFill an input field by uidText inputs, textareas
fill_formFill multiple form fields at onceForms with multiple inputs
type_textType text (keyboard-level)Typing into focused elements
press_keyPress a specific keyEnter, Escape, Tab, arrow keys
hoverHover over an element by uidHover states, tooltips
select_pageSwitch to a different page/tabMulti-page workflows
evaluate_scriptExecute JavaScript in page contextRuntime state, custom assertions
list_console_messagesList browser console messagesRuntime errors, exceptions, warnings
get_console_messageGet details of a specific console messageInspecting a particular error
list_network_requestsList network requestsChecking API calls, failed requests
get_network_requestGet details of a specific requestInspecting request/response payloads
wait_forWait for a condition (element, text, network idle)Ensuring page is loaded before interacting
resize_pageResize the browser viewportTesting responsive layouts
close_pageClose a browser pageCleanup after testing
lighthouse_auditRun a Lighthouse auditPerformance and accessibility checks

Workflow Pattern (chrome-devtools-mcp)

  1. list_pages → check availability
  2. new_page → open fresh page
  3. navigate_page → load the app URL
  4. wait_for → ensure content is loaded
  5. take_snapshot → get element uids
  6. click / fill / press_key → interact using uids from snapshot
  7. take_snapshot or take_screenshot → verify outcome
  8. list_console_messages → check for errors

Screenshots (chrome-devtools-mcp)

Use take_screenshot. For large pages, use the filePath parameter to save directly to disk.


Dev Server Detection

Detection follows a priority order. Stop at the first successful detection.

Step 1: Context sources (primary)

Check these first — developers often document their dev commands:

  • CLAUDE.md in the target project — look for dev server commands, URLs, or run instructions
  • Prior chat context — the developer may have mentioned the command or URL earlier in the conversation

Step 2: Ecosystem analysis (fallback)

If context sources don't have the info, analyze the project:

EcosystemFiles to checkCommon dev commandsDefault URL
Node.js / npmpackage.json scriptsnpm run dev, npm start, next dev, vitehttp://localhost:3000
Pythonmanage.py, pyproject.tomlpython manage.py runserver, flask run, uvicornhttp://localhost:8000
RubyGemfile, Procfilerails server, bundle exec rails shttp://localhost:3000
Gogo.mod, Makefilego run ., make devhttp://localhost:8080
RustCargo.tomlcargo run, trunk servehttp://localhost:8080
Javapom.xml, build.gradle./mvnw spring-boot:run, ./gradlew bootRunhttp://localhost:8080
Elixirmix.exsmix phx.serverhttp://localhost:4000

Step 3: Ask the developer

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?"


Graceful Degradation

Dev mode (called from bee:sdd)

  • Report: "Browser verification skipped — no browser MCP provider available"
  • Do not block the build. The regular verifier result (PASS) stands.
  • The slice still passes. Browser verification is additive, not required.

Test mode (called from bee:browser-test)

  • Report the specific issue (no provider found, or browser not connected) with the install instructions from Provider Detection Step 3.
  • Stop. There is no fallback — browser testing is the entire purpose of this command.

Screenshot Conventions

When to capture

  • Dev mode: Only on failure — screenshot the failing state for developer review
  • Test mode: Both pass and fail — full audit trail for regression reports

Storage path

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.

Referencing in reports

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"
Stats
Stars3
Forks0
Last CommitMar 11, 2026

Similar Skills