Install any skill in seconds. Free to start, no credit card required.
Get Started Free →xuzhougeng/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
Passed 12 of 20 test cases with the skill, and 8 of 20 without it.
and 5 more in the full report
6 fixed8 passed either way8 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
I want to send a query through the Google Search AI Mode tab using the in-browser chat workflow. The target URL is 'https://google.com/search?q=quantum+computing'. Is this URL accepted by web_agent_send?
| Checked | Without skill | With skill |
|---|---|---|
| Rejects the search URL because it lacks the udm=50 parameter | Missed | Passed |
The instructions your model reads when the skill loads.
Wisp talks to the Browser Runtime. Shared mode uses the user's daily
Chrome via the unpacked extension — every action runs in their real
profile: existing cookies, logins, extensions, and normal fingerprint all
apply. Workspace mode can launch a separate Chrome profile. If both are
connected, pass session: "shared" or session: "workspace". If
Settings → Browser has Open browser automatically enabled (the
default) and no extension is connected, Wisp may start the installed
Chrome/Chromium/Edge so the extension can reconnect. That is still the
user's profile, not Playwright or Selenium.
Shared is the default; workspace is not a fallback. Google Chrome 137
and later ignore --load-extension, so on a machine with only branded
Chrome the workspace window cannot load the Wisp extension at all.
browser_setup {"action":"start_workspace"} therefore returns only once
the workspace extension has connected, and otherwise closes the window
and fails with WORKSPACE_EXTENSION_BLOCKED. On that error: relay the
message, do not retry start_workspace, do not claim any workspace page
was opened or read, and get the shared session working instead.
For figures/code extraction use web_scan with mode: "article" then
web_save_assets. For an already-logged-in in-browser chat (ChatGPT,
Gemini, or Google AI Mode at google.com/search?udm=50) use
web_agent_send, web_agent_wait, web_agent_read on that tab.
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.
Call browser_setup. If status is not connected (or live_retrieval
is false), relay its steps (load the unpacked extension from
extension_path, verbatim) and stop. Do not answer live, latest,
current, or URL-specific questions from prior knowledge. Tell the user
this turn contains no live web retrieval and wait until the popup shows
Connected to Wisp. Only continue from memory if they explicitly ask
for a knowledge-only answer. Never invent the path.
Two fields say why a browser that looks connected is not usable —
test cases passed, vs 8 / 20 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.