drisp-browser

Drisp Browser Guide

Use this skill to open live web pages, carry out actions, move through multi-step flows, validate page state, and capture selectors for automation.

Common uses:

• Review a live page or multi-step flow
• Click through navigation, buttons, dialogs, and other actions
• Fill, submit, or inspect forms and validation states
• Add products to cart or complete other in-page actions
• Capture reliable Playwright selectors for key elements

Setup

This skill drives the Drisp Browser (@drisp/browser-mcp) MCP server — installing the skill does not install that server. If the mcp__drisp-browser__* tools aren't available, add the server first:

claude mcp add drisp-browser -- npx @drisp/browser-mcp@latest

For Claude Desktop / Cursor / VS Code, register it under the key drisp-browser:

{
  "mcpServers": {
    "drisp-browser": {
      "command": "npx",
      "args": ["@drisp/browser-mcp@latest"]
    }
  }
}

See the Drisp Browser README for browser modes (user, persistent, isolated) and options.

Why this skill must load before browser MCP calls: without it, browser work reliably produces brittle CSS selectors, narrative prose instead of structured observations, missed state transitions, and shallow page coverage. The selector-capture and state-observation patterns below are what the downstream exploration report, spec generation, and test-writing skills depend on.

Subagent dispatch: when a subagent is dispatched with browser MCP access, this is the first skill it should load — the exploration upstream of spec generation and test writing depends on the patterns below.

Input

Parse the target URL and exploration goal from: $ARGUMENTS

Workflow

1. Navigate or recover the right page — use list_pages and explicit page_id when session state may be ambiguous
2. Orient first — read the current state, active region, and visible controls before acting
3. Choose the lightest useful tool
   • Use page state or snapshot output for quick orientation
   • Use find with label, kind, and region to narrow targets
   • Use get_form when the task is clearly form-driven
   • Use get_element for a chosen target, offsets, or selector extraction
4. Act one step at a time — click, type, select, scroll, or drag only as needed to advance the task
5. Reacquire state after meaningful changes — after navigation, overlays, search expansion, dialog opening, or large DOM updates, refresh your understanding before reusing old eids
6. Inspect forms or extract selectors only when relevant — do this when asked for them or when they materially help complete the task
7. Report what you did, what happened, and any selectors or form details that matter