Drive Chrome via CDP for authenticated scraping and JS-heavy automation

This skill provides direct browser control via Chrome DevTools Protocol (CDP) for tasks that need a real logged-in browser, visible interaction, or JS-heavy page control - as opposed to a static fetch. It's invoked as the browser-harness CLI (on $PATH, no cd/uv run needed) with inline Python where helpers are pre-imported and the daemon auto-starts; first navigation always uses new_tab(url) rather than goto_url(url), since goto runs in the user's active tab and would clobber their work. A routing check comes first: if the task needs no interaction at all and just wants page content, it defers to a separate deepapi skill's scrape endpoint instead of driving a real browser. For parallel sub-agents or headless servers, start_remote_daemon spins up an isolated cloud browser per session (keyed by a distinct BU_NAME), optionally reusing a saved cloud profile or applying a proxy country code and timeout; it prints a live URL so a user can watch along, and the daemon keeps billing until its timeout, PATCHing the cloud browser to stop and persist profile state on shutdown. The documented "what actually works" pattern favors screenshots-first interaction: capture a screenshot, read the target pixel coordinates off the image, click with click_at_xy(x, y), then screenshot again to verify - deliberately suppressing the Playwright habit of locating a selector before clicking, since hit-testing happens in Chrome's browser process and passes through iframes, shadow DOM, and cross-origin content without extra work. It drops to DOM-level js(...) calls only when a target has no visible geometry, uses bulk http_get() plus a thread pool for static pages instead of a browser, calls wait_for_load() after every navigation, and calls ensure_real_tab() to recover from a stale or internal tab. Hitting an auth/login wall means stopping and asking the user rather than typing credentials from a screenshot. A proven pattern for authenticated content extraction (X/Twitter articles, LinkedIn, paywalled sites where generic scrapers fail) navigates with new_tab/wait_for_load, sleeps several seconds for JS-heavy rendering, extracts via document.querySelector("article").innerText (or document.body.innerText as fallback), and writes the result to a temp file to avoid shell-escaping issues with large text - relying on the user's own already-authenticated browser session. A library of reusable interaction-skills/ files covers mechanics like dialogs, dropdowns, iframes, cross-origin iframes, shadow DOM, drag-and-drop, uploads, downloads, and profile syncing. Optional, off-by-default "domain skills" (BH_DOMAIN_SKILLS=1) hold community-contributed per-site playbooks under agent-workspace/domain-skills/<site>/, meant to be read before inventing an approach on a matching site, and extended with durable, non-secret site knowledge (stable selectors, URL patterns, quirks) rather than pixel coordinates or task narration. Field-tested gotchas include: Brave uses brave://inspect/#remote-debugging instead of Chrome's URL but is otherwise auto-discovered; omnibox popups are fake page targets to filter out; CDP target order doesn't match the visible tab strip; the Browser Use remote API is camelCase on the wire and its cdpUrl is HTTPS rather than a raw websocket URL; and re-screenshotting after every meaningful action is the default way to verify state actually changed.

Use it when a task needs a real, logged-in browser, visible interaction, or control over a JS-heavy page - not when a static fetch would do, which should go through the deepapi scrape skill instead. Do NOT launch a separate browser instance - connect to the user's already-running Chrome (or Brave) so existing login sessions carry over. Do NOT type credentials on behalf of the user when hitting an auth wall - stop and ask instead. Avoid adding a manager layer (retries framework, session manager, config system) on top of the harness's deliberately tiny core.

Inputs: a target URL and the interaction needed (click, form fill, scroll, extraction), plus optional remote-session parameters (profile name/ID, proxy country, timeout) for cloud browsers. Outputs: page state confirmed via page_info() or screenshots, extracted text/DOM content (e.g. written to a temp file), or a completed UI interaction, verified by a follow-up screenshot.

browser-harness -c '
new_tab("https://docs.browser-use.com")
wait_for_load()
print(page_info())
'

Built on Chrome DevTools Protocol, connecting to the user's real Chrome or Brave browser (Brave auto-discovered via its own remote-debugging flag). Remote/parallel use goes through the Browser Use cloud API (BROWSER_USE_API_KEY, start_remote_daemon, cloud profile sync). Defers non-interactive page fetches to the companion deepapi skill, and integrates with Hermes Agent as an installed skill (with a documented frontmatter rename needed to avoid colliding with Hermes's built-in browser toolset).

Agents and engineers automating real, authenticated browser interactions - JS-heavy SPAs, login-walled content extraction, or visual verification - where a static page fetch isn't sufficient.