DOCSEARCHbyAlgolia
Submit Docs

Browserbase Skills

repository·main·Indexed 25 days ago

https://github.com/browserbase/skills

A collection of plugins for AI coding agents, such as Claude Code, to perform web automation, research, and UI testing using Browserbase infrastructure. Includes specialized skills like autobrowse for self-improving automation, ui-test for adversarial UI testing, and tools for company research, competitor analysis, and browser-to-API conversion.

Tokens
99.4K
Snippets
191
Records
386
Agent score
86%

What's inside browserbase-skills

  1. Audit Agent Experience with the agent-experience skill

    main

    The agent-experience skill evaluates the developer experience (DX) of a product, SDK, documentation site, or SKILL.md file by having multiple Claude subagents attempt to onboard and perform tasks using only a minimal, one-sentence prompt.

    Instead of providing instructions, the subagents are given a tiny task (e.g., "Get started with {product} and {do its primary thing}") and must discover documentation, install dependencies, and handle credentials themselves. The skill captures tool-call traces (retries, wall time, errors) and generates an HTML report with an A–F grade based on Setup Friction, Speed, Efficiency, Error Recovery, and Doc Quality.

    **Use this skill when you want to:

    • Audit agent experience or test a specific skill.
    • Audit documentation specifically for AI agents.
    • Check if an SDK is agent-friendly.
    • Validate a SKILL.md file.
    • Measure agent DX or benchmark onboarding friction.

  2. Understand the browse CLI architecture

    main

    The browse CLI operates as a daemon-based tool. A background daemon process manages the browser instance, which automatically starts upon the first command (e.g., browse open) and persists across subsequent commands. To terminate the background process, use browse stop.

    There are two primary modes of operation:

    • Local mode: Runs a clean, isolated local browser. This is the default behavior if the BROWSERBASE_API_KEY environment variable is not set.
    • Remote mode (Browserbase): Connects to a Browserbase cloud browser session when BROWSERBASE_API_KEY is provided.

    The tool follows an accessibility-first pattern: you can use browse snapshot to retrieve the page's accessibility tree containing element references, which are then used for subsequent interactions.

  3. Understand ui-test testing capabilities

    main

    The ui-test skill provides adversarial and exploratory testing that goes beyond traditional Playwright scripts. It covers:

    CategoryMethod
    AccessibilityUses axe-core and keyboard navigation to find WCAG violations and focus issues.
    Visual QualityUses screenshots and Claude judgment to evaluate layout, typography, and spacing.
    ResponsivePerforms a viewport sweep (375px, 768px, 1440px) to check for mobile overflow and reflow.
    Console HealthInjects browse eval to detect hydration errors, failed requests, and runtime exceptions.
    Error StatesNavigates to empty or error states to check for broken recovery.
    AdversarialTests edge cases like XSS, empty submits, rapid clicking, and long inputs.
    ExploratoryNavigates freely to find bugs not covered by predefined test cases.

  4. Use Browser Trace to debug browser automation

    main

    The browser-trace skill allows you to attach a read-only CDP (Chrome DevTools Protocol) client to an active browser session. It captures a full DevTools firehose (NDJSON), parallel screenshots, and DOM dumps, then organizes them into searchable per-page buckets.

    Use this when you need to:

    • Debug failed automation (missing elements, JS exceptions, hung navigation).
    • Audit network, console, or DOM activity.
    • Attach a trace to a running session mid-flight.
    • Feed structured per-page summaries back into an AI agent loop.

    Note: This skill only listens; it does not drive the browser. Use the browser skill to perform actions.

  5. Generate an OpenAPI spec from browser traffic with browser-to-api

    main

    The browser-to-api skill converts a browser-trace capture into an OpenAPI 3.1 specification and a human-readable coverage report. It analyzes HTTP traffic (requests/responses) to infer JSON schemas, template URLs, and identify API endpoints.

    Note: This skill is a post-processor. You must first capture traffic using the browser-trace skill. For full response-body schema inference, you must use browse network on during the capture phase.

  6. Understand Event-Prospecting Output Formats

    main

    The event-prospecting skill generates two types of markdown files in a per-run Desktop directory ({OUTPUT_DIR}). These files use YAML frontmatter for structured data and markdown bodies for human-readable research.

    1. Company files: Located at {OUTPUT_DIR}/companies/{slug}.md. These exist in two states:
      • Triage Stubs (Step 5): A lightweight assessment for every company in seed_companies.txt.
      • Deep Research (Step 7): A richer version that overwrites the triage stub if the icp_fit_score meets the --icp-threshold.
    2. Person files: Located at {OUTPUT_DIR}/people/{slug}.md. These are created in Step 8 only for speakers at companies that underwent deep research (triage_only: false).

  7. Quickstart: Trace a local Chrome session

    main

    To trace a local Chrome instance, follow these steps:

    1. Launch Chrome with a remote debugging port and an isolated user data directory.
    2. Start the tracer using start-capture.mjs.
    3. Run your automation against the specified port using the browse CLI.
    4. Stop and bisect the results to generate organized logs.
    # 1. Launch Chrome with a debugger port
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-o11y \
  about:blank &

# 2. Start the tracer
node scripts/start-capture.mjs 9222 my-run

# 3. Run your main automation against port 9222
browse open https://example.com --cdp 9222
# ...whatever the run does...

# 4. Stop and bisect
node scripts/stop-capture.mjs my-run
node scripts/bisect-cdp.mjs my-run
    # 1. Launch Chrome with a debugger port (any user-data-dir keeps it isolated).
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-o11y \
  about:blank &

# 2. Start the tracer.
node scripts/start-capture.mjs 9222 my-run

# 3. Run your main automation against port 9222.
browse open https://example.com --cdp 9222
# ...whatever the run does...

# 4. Stop and bisect.
node scripts/stop-capture.mjs my-run
node scripts/bisect-cdp.mjs my-run

  8. Quickstart: Trace a Browserbase remote session

    main

    When using Browserbase, use the bb-capture.mjs and bb-finalize.mjs helpers to manage sessions and artifacts.

    Important: Browserbase ends a session as soon as its last CDP client disconnects. Use the --keep-alive flag when creating a session to ensure the tracer can attach.

    Create a new session and trace

    export BROWSERBASE_API_KEY=...

# 1. Create a keep-alive session AND start the tracer
node scripts/bb-capture.mjs --new my-run

# 2. Drive automation using the session's connectUrl
SID=$(jq -r .browserbase.session_id .o11y/my-run/manifest.json)
CONNECT_URL="$(browse cloud sessions get "$SID" | jq -r .connectUrl)"
BROWSE_NAME=my-run-browser
browse open https://example.com --cdp "$CONNECT_URL" --session "$BROWSE_NAME"
browse open https://news.ycombinator.com --session "$BROWSE_NAME"

# 3. Stop, bisect, and pull artifacts
node scripts/stop-capture.mjs my-run
node scripts/bisect-cdp.mjs my-run
node scripts/bb-finalize.mjs my-run --release

    Attach to an existing running session

    If you have a running session (e.g., from a production worker), you can attach the tracer mid-flight without disruption:

    # Find a running session ID
browse cloud sessions list | jq -r '.[] | select(.status == "RUNNING") | .id'

# Attach tracer to the session
node scripts/bb-capture.mjs <session-id> mid-flight-debug

# Stop and process
node scripts/stop-capture.mjs mid-flight-debug
node scripts/bisect-cdp.mjs mid-flight-debug
node scripts/bb-finalize.mjs mid-flight-debug   # omit --release to keep session running
    export BROWSERBASE_API_KEY=...

# 1. Create a keep-alive session AND start the tracer in one step.
node scripts/bb-capture.mjs --new my-run

# 2. Drive automation. bb-capture stamped the session id into the manifest.
SID=$(jq -r .browserbase.session_id .o11y/my-run/manifest.json)
CONNECT_URL="$(browse cloud sessions get "$SID" | jq -r .connectUrl)"
BROWSE_NAME=my-run-browser
browse open https://example.com --cdp "$CONNECT_URL" --session "$BROWSE_NAME"
browse open https://news.ycombinator.com --session "$BROWSE_NAME"

# 3. Stop the tracer, bisect, then pull platform artifacts and release.
node scripts/stop-capture.mjs my-run
node scripts/bisect-cdp.mjs my-run
node scripts/bb-finalize.mjs my-run --release

  9. Test Keyboard Navigation and Tab Order

    main

    Verify that all interactive elements are reachable via the Tab key and that the focus order follows the visual layout.

    Repeat the browse press Tab and browse eval sequence until document.activeElement returns the BODY tag.

    browse open "TARGET_URL"
browse wait load

# Tab through elements one at a time
browse press Tab
browse eval "JSON.stringify({tag: document.activeElement?.tagName, text: document.activeElement?.textContent?.trim().slice(0,40), role: document.activeElement?.getAttribute('role'), ariaLabel: document.activeElement?.getAttribute('aria-label'), hasFocus: (() => { const s = window.getComputedStyle(document.activeElement); return s.outlineStyle !== 'none' || s.boxShadow !== 'none'; })()})"

  10. Perform Diff-Driven Component Testing

    main

    Use the browse CLI to verify UI changes by comparing snapshots before and after an action. This pattern is useful for ensuring that code changes (like updating button text) result in the expected UI state without breaking functionality or introducing side effects like duplicate dialogs during rapid clicks.

    Workflow:

    1. Analyze changes: Use git diff to identify modified files.
    2. Setup: Open the local URL and wait for it to load.
    3. Baseline: Take a browse snapshot to capture the state before the change.
    4. Action: Perform the interaction (e.g., browse click <selector>).
    5. Verification: Take another browse snapshot to confirm the new state and ensure the page remains stable.
    # Analyze diff
git diff --name-only HEAD~1
git diff HEAD~1 -- src/components/HeroSection.tsx

# Setup
browse open http://localhost:3000/ --local
browse wait load

# BEFORE snapshot
browse snapshot

# Happy path: button is clickable
browse click @0-8
browse snapshot

# Adversarial: rapid click
browse open http://localhost:3000/
browse wait load
browse snapshot
browse click @0-8
browse click @0-8
browse click @0-8
browse snapshot

browse stop

  11. Optimize Stagehand for deterministic runs

    main

    Follow these best practices to improve the reliability and performance of your Stagehand scripts:

    • Wait for page stability: Use await page.waitForLoadState("domcontentloaded") or "load". Avoid "networkidle" as it may timeout on sites with continuous background traffic.
    • Scope extractions: Use the selector option to reduce noise and cost: extract("…", schema, { selector: "//main" }).
    • Lock the viewport: Use await page.setViewportSize(width, height) to ensure cached selectors remain valid. Note that in v3, these are positional arguments.
    • Use variables: Pass inputs via variables to allow different inputs to share a single cache entry and to keep secrets out of prompts.
    • Anchor to UI labels: Use visible text (e.g., "click the Sign in button") rather than internal DOM structure.
    • Handle loops in TypeScript: Instead of asking the AI to loop, use extract to get a list, then iterate using plain TypeScript.
    • Resolve absolute URLs: When navigating from extracted links, use new URL(href, page.url()).toString() to avoid invalid URL errors.

  12. Requirements for Playwright codegen system prompts

    main

    When generating Playwright scripts from autobrowse traces, the generated .ts file must adhere to these strict operational constraints:

    • Environment: The script must be self-contained and only require BROWSERBASE_API_KEY in the environment. It cannot rely on local workspace files or autobrowse state.
    • Session Management:
      • Use connectOverCDP to attach to a session; never use chromium.launch().
      • Do not use browser.close(). Instead, release the session in a finally block by executing: browse cloud sessions update <id> --status REQUEST_RELEASE.
    • Error Handling: Wrap the main() function in a try/catch block. In the catch block, use await snap(page, '99-error') to capture a screenshot. Respect the process.env.SCREENSHOT_DIR environment variable for the output path.
    • Locators: Follow this priority order: data-testid attribute $\rightarrow$ role + name $\rightarrow$ id $\rightarrow$ text $\rightarrow$ xpath. Use descriptor data (attributes, role, accessibleName) from the trace when available. Prefer Playwright's auto-waiting methods over explicit sleeps.
    • Network: Use page.waitForResponse(...) based on trace network signals instead of arbitrary sleeps.
    • Output Format: The very last line of stdout must be a single JSON object: {"success":true,"data":...} or {"success":false,"error":"..."}. Do not emit any other JSON-like lines after this.