xuzhougeng/wisp-science
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
npx skills add https://github.com/xuzhougeng/wisp-science --skill "skills/browser-use"Quick start
Install it or open the source, trigger it with a clear task, then follow the source workflow.
npx skills add https://github.com/xuzhougeng/wisp-science --skill "skills/browser-use"Use browser-use to help me with: [describe your task]. Before you begin, tell me what input you need, the steps you will follow, and the expected output.
No structured workflow was detected; follow the original SKILL.md below.
Continue to the workflowDirect answers
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…
It is relevant to workflows involving the tasks described in the upstream documentation.
SkillSignal detected this source-specific command: npx skills add https://github.com/xuzhougeng/wisp-science --skill "skills/browser-use". Inspect the repository and command before running it.
The upstream source does not declare a dedicated Agent platform.
No obvious permission action was detected by the static rules. This is not proof that the Skill is safe.
This page combines upstream documentation with deterministic repository, quality, and static-risk signals. It is not described as a manual test or security review.
SkillSignal brief
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…
Useful in these contexts
Core capabilities
Quality breakdown
Based on traceable docs and repository signals; stars are not treated as quality.
Compare before choosing
These links are selected from shared tasks, functions, stacks, platforms, and same-name variants. Compare the source owner, documentation, permissions, and maintenance signals.
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program
When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers o
Grounded design brief from the adopted corpus — style, WCAG-checked color tokens, typography, layout pattern, anti-patterns. Use on ui-design-brief or any which-style/palette/font/chart decision.
Write and maintain DESIGN.md + PRODUCT.md — captures visual decisions and interaction patterns so design tasks stay consistent across sessions without re-scanning past work.
Use BEFORE writing or editing any non-trivial UI — inventories components, design tokens, shadcn primitives, and reusable patterns into state.ui_audit. Hard gate for the ui directive set.
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.
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.
web_open_tab {url} — open the page (works even with no tab
open yet). Returns the new tab id.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:<id> to pin one.web_execute_js — act, then re-scan to confirm the effect.web_execute_js script)| Goal | script |
|---|---|
| Click | document.querySelector('<selector>').click() |
| Type into a field | const e=document.querySelector('<sel>'); e.value='text'; e.dispatchEvent(new Event('input',{bubbles:true})); e.dispatchEvent(new Event('change',{bubbles:true})) |
| Submit a form | click the submit control by its selector, then re-scan |
| Navigate current tab | location.href='https://example.com' |
| Read a value | document.querySelector('<sel>').textContent |
script may instead be a JSON command:
| Goal | JSON command |
|---|---|
| Switch to & focus a tab (so the user sees it) | {"cmd":"tabs","method":"switch","tabId":<id>} |
| List tabs | {"cmd":"tabs"} (or just web_scan tabs_only) |
| Close tabs you opened | {"cmd":"tabs","method":"close","tabIds":[<id>,...]} — returns closed + remaining |
Trusted click when .click() is ignored | {"cmd":"cdp","method":"Input.dispatchMouseEvent","params":{"type":"mousePressed","x":<x>,"y":<y>,"button":"left","clickCount":1}} then the same with "type":"mouseReleased" — use the element's rect centre from web_scan |
Prefer plain JS. Reach for cmd:cdp only when a page blocks synthetic
events or you truly need trusted input.
web_screenshotweb_scan gives text and elements; web_screenshot gives sight. Use it
when structure isn't enough: rendered layout, a chart or diagram, a
canvas/WebGL page, a QR code, a PDF or image viewer, or a page that looks
broken. It captures the visible viewport of the tab — to see below the
fold, scroll first (web_execute_js scrollTo(0, 1200)) and capture again.
Pass question to say what to read out of it, e.g.
{"question":"is the login QR code visible and not expired?"}.
It goes through the configured vision model, so web_scan stays the cheaper
default — screenshot when you need eyes, not for every step.
Browsing tasks (searching papers, opening a dozen results) leave the user with a pile of tabs to close by hand. So:
web_open_tab returns tab.id. Keep a running list of the ids
you opened in this task, in your own message text — e.g. after a batch
write opened tabs: 1234, 1235, 1236. {"cmd":"tabs"} cannot tell you
which tabs are yours, only what exists.{"cmd":"tabs","method":"close","tabIds":[1234,1235,1236]}. Report
closed; ids already gone are skipped silently.Close only ids you opened yourself. Tabs the user had open, or ones they opened during the task, are theirs — never include them, and never close a tab mid-task that later steps still need.
web_scan returns
human_intervention.required=true, stop, ask the user to complete the
challenge in the visible tab, and wait for their confirmation before
scanning again.browser_setup (download_automation) and wait for the
user to confirm; until then trigger at most one download.