browser-use
Use this skill to drive the user's real, persistent Chrome/Chromium session — open pages, read them, click, fill and submit forms, navigate, switch tabs, or scrape content that needs the user's existing cookies and login state. Triggers when the user asks to do something in their browser, log into a site and act inside it, fill out a web form, click through a flow, or extract data from a page that requires being signed in. Tools: browser_setup (check/connect the extension), web_open_tab (open a URL), web_scan (read visible content + actionable elements with ready-made selectors), web_execute_j
npx skills add xuzhougeng/wisp-science --skill browser-use --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Browser Use — act inside the user's real Chrome Wisp does **not** launch an automation browser. It talks to a small extension inside the user's own Chrome/Chromium, so every action runs in their real profile — existing cookies, logins, extensions, and normal fingerprint all apply. That is the whole point: you can operate pages the user is already signed into. Every `web_scan` and `web_execute_js` call needs the user's approval by design. Do not treat that as a bug to route around. ## Before anything: confirm the bridge is live Call `browser_setup`. If `status` is not `connected`, relay its `steps` (load the unpacked extension from `extension_path`, verbatim) and stop until the popup shows *Connected to Wisp*. Never invent the path. ## The loop 1. **`web_open_tab`** `{url}` — open the page (works even with no tab open yet). Returns the new tab id. 2. **`web_scan`** — read the page. Returns `page.text`, `page.title`, and `page.elements[]`, where each element carries a **unique `selector`**, its visible `text`/`aria_label`, and a `rect` `[x,y,w,h]`. Use these selectors directly — do not guess. Use `tabs_only:true` first when you are unsure which tab to target; pass `switch_tab_id:<i
- Before anything: confirm the bridge is live
- The loop
- Recipes (webexecutejs script)
- Seeing the page — webscreenshot
- Tab hygiene — track what you open, offer to close it
- Stop conditions (do not automate through these)
What does the browser-use skill do?
Use this skill to drive the user's real, persistent Chrome/Chromium session — open pages, read them, click, fill and submit forms, navigate, switch tabs, or scrape content that needs the user's existing cookies and login state. Triggers when the user asks to do something in their browser, log into a site and act inside it, fill out a web form, click through a flow, or extract data from a page that requires being signed in. Tools: browser_setup (check/connect the extension), web_open_tab (open a URL), web_scan (read visible content + actionable elements with ready-made selectors), web_execute_j
How do I install it?
Run `npx skills add xuzhougeng/wisp-science --skill browser-use --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From xuzhougeng/wisp-science, a repository with 895 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.