BB-fat
ce11325de2
Progressive disclosure, final stage: with lazyTools on (default), the eleven browser_* tool schemas stay out of the system prompt — the browser-skill catalog entry is the sole advertisement. One successful skill invocation (model tool call via tools/result, or a /browser-skill user gesture via the session append feed) registers the suite for the process lifetime, idempotent on repeats; session resume is covered by scanning durable events for a past tool/call+tool/result pair (or skill-invocation message) on session entry and at apply time. lazyTools: false keeps the legacy always-on registration. Investigation (recorded in the ticket): tools/result carries normalized name/arguments with an isError discriminant; dsh 0.1 has no official global visibility switch (ctx.tools.restrict is agent-scoped and throws from a plain context), making conditional registration the intended pattern; per-step assembly picks the new suite up on the next step, and visibility changes are first-class inputs of tool-skill's catalog digest. registerTools now returns the combined disposer via a prototype-preserving tracking overlay; the skill prelude tells the model the browser_* tools unlock on skill load. Tests: +8 (hidden-before/reveal/idempotent/gesture/history hit+miss/dispose/ scanner pairing/two-state apply wiring). 124/124 green.
2.8 KiB
browser-skill (dsh edition)
Drive the user's real Chromium browser (logins, cookies, Agent Window isolation)
through this plugin's browser_* tools. Each tool spawns bsk <cmd> --json — the
same engine the canonical CLI skill documents — so the workflow, judgment rules, and
safety constraints are identical.
Tool availability: invoking this skill (which you just did) makes the plugin's
browser_*tools available for the rest of the session — they are injected on successful skill load. Until then they are deliberately hidden, so do not attempt a browser action before loading this skill.
Tool ↔ CLI map
The tools below are thin, structured wrappers over the bsk CLI verbs of the same
name; session parameters take the 4-letter session id (no --session flag
spelling here):
| dsh tool | bsk equivalent |
|---|---|
browser_session_start / browser_session_stop / browser_session_list |
bsk session start/stop/list |
browser_navigate |
bsk navigate |
browser_snapshot / browser_observe |
bsk snapshot / bsk observe |
browser_click / browser_fill / browser_press |
bsk click / bsk fill / bsk press |
browser_screenshot |
bsk screenshot |
browser_emulate |
bsk emulate |
(bsk console / bsk network have no tool counterpart in this plugin yet.)
Plugin-specific semantics that override or narrow the CLI rules below:
- Owned sessions only: this plugin sees and acts on just the sessions IT
started via
browser_session_start.browser_session_listshows only those (with the current marker); passing a session id created by another program (or person) sharing the bsk daemon is refused outright — never retry those with the same id. - Current session: omitted
sessionparameters resolve to the most recently started or used OWNED session. With several sessions in flight, passsessionexplicitly to avoid surprises. - Screenshots: when the model route accepts images,
browser_screenshotreturns the PNG inline as an image attachment; otherwise it returns the saved file path. browser_emulate mobile: requireswidth+height— the bsk daemon refuses--mobilewithout viewport dimensions.- Live observation: in the dsh Web UI, every owned session is watched by the floating overlay (thumbnails, action, interrupt) — observational side traffic is free and never steals your command turn; just keep acting.
The canonical CLI skill body follows verbatim (source of truth: skill/SKILL.md
in the BrowserSkill repo, mirrored by build into crates/bsk-cli/skill/SKILL.md).
Read bsk <verb> --session <id> as "the browser_<verb> tool with
session: <id>"; everything else — when to use, the stop-when-done rules, the
interaction loop, refs, sandbox rules — applies unchanged.