Pup - the AI's own browser

@@ -1,7 +1,7 @@ --- name: pup user-invocable: true-description: "Drive a browser on the user's desktop from the cloud: the Puppeteer 'pup' bridge (pup_* verbs via the adom-bridge-cli CLI). To the user these are PUP WINDOWS, full stop: never name the browser build or how pup drives it unless they ask. pup runs its own browser in a pup-managed DURABLE profile (logins/localStorage persist and are shared across pup windows), driven through pup's own extension channel with no debug port, which is the lane every vendor site loads on and the ONLY lane pup opens unless you pass lane:'cdp' for a CDP-only feature (see the pup-lanes skill), in the BACKGROUND so it never disturbs the user; NOT the user's real signed-in profile (that is the Adom extension's nbrowser_* verbs), NOT headless (a real rendered window, so screenshots/recording are true-to-life). Open/close windows + tabs, navigate, screenshot, eval JS, record. This is the START-HERE skill: the mental model + when-to-use + the skill map; deeper topics route to the sub-skills. For 'is it ready' use pup_readiness (not pup_status). Trigger words: pup, puppeteer, browser window, open in pup, open my app in pup, browser screenshot, browser eval, browser reload, visual debug, headful chrome, pup_open_window, pup_screenshot, pup_readiness, pup_prewarm, chrome for testing, open in browser, open my web app, show my app in the browser, preview my app, open the app I just built, view my app, open localhost, show my dev server, pup_login, log into a site in pup, autofill password, saved login, durable profile, isolated window."+description: "Drive a browser on the user's desktop from the cloud: the Puppeteer 'pup' bridge (pup_* verbs via the adom-bridge-cli CLI). To the user these are PUP WINDOWS, full stop: never name the browser build or how pup drives it unless they ask. pup runs its own browser in a pup-managed DURABLE profile (logins/localStorage persist and are shared across pup windows), driven through pup's own extension channel with no debug port, which is the lane every vendor site loads on and it speaks the full DevTools protocol (CDP) through that extension, so every pup window has CDP-level access (pup_devtools for any raw command) even where the separate CDP lane is off: never give up or switch machines because 'CDP is off', in the BACKGROUND so it never disturbs the user; NOT the user's real signed-in profile (that is the Adom extension's nbrowser_* verbs), NOT headless (a real rendered window, so screenshots/recording are true-to-life). Open/close windows + tabs, navigate, screenshot, eval JS, record. This is the START-HERE skill: the mental model + when-to-use + the skill map; deeper topics route to the sub-skills. For 'is it ready' use pup_readiness (not pup_status). Trigger words: pup, puppeteer, browser window, open in pup, open my app in pup, browser screenshot, browser eval, browser reload, visual debug, headful chrome, pup_open_window, pup_screenshot, pup_readiness, pup_prewarm, chrome for testing, open in browser, open my web app, show my app in the browser, preview my app, open the app I just built, view my app, open localhost, show my dev server, pup_login, log into a site in pup, autofill password, saved login, durable profile, isolated window." ---  # Pup: browser control on the user's desktop (start here)@@ -23,6 +23,20 @@ adom-bridge-cli --ai-thread "<your thread>" pup_open_window '{"url":"https://exa adom-bridge-cli --ai-thread "<your thread>" pup_screenshot  '{}'                              # zero-id: resolves to YOUR window ``` +## pup windows have CDP-level access: never give up because "CDP is off"++Every pup window is driven through pup's own browser extension, which speaks the full DevTools protocol (CDP) to the+page with no debug port. So you have everything CDP gives you on every pup window, on every box:+trusted clicks and keys (`pup_click`, `pup_type`, `pup_input_dispatch`), `pup_eval`, element and full-page+screenshots, downloads, fetches, HTTP auth, and `pup_devtools {method, params}` for any other DevTools command+(DOM, Runtime, Input, Page, Network, Emulation, iframes through `Page.getFrameTree`).++The separate "CDP lane" (`lane:"cdp"`, a window with a debug port) is OFF on most boxes, and you do not need it. Never+tell the user "CDP is switched off, so pup can't do this here", never move the task to another machine for that reason,+and never ask for `lane:"cdp"` to get a feature: since 2.0.726 a `lane:"cdp"` open on a box with that lane off simply+opens on the extension lane and says so. If something truly cannot be done, report the exact verb and error on+adom/pup-bridge as an extension-lane gap and keep going with what works.+ ## Logins: pup manages your credentials (no Chrome picker)  pup runs its OWN password manager, so the AI signs into sites without Chrome's foreground autofill

@@ -1,6 +1,6 @@ {   "slug": "pup-bridge",-  "version": "2.0.725",+  "version": "2.0.726",   "type": "app",   "description": "The pup SKILL PACK: the AI skills that teach a cloud/container AI how to drive the Bridge Puppeteer (pup) bridge (pup_* verbs): the everyday `pup` skill plus focused sub-skills for windows/sessions/tabs, screenshots+recording, browsers+Chrome install, and driving the Adom wiki. Installs into ~/.claude/skills + ~/.codex/skills. DOCS ONLY \u2014 this is NOT the bridge runtime. The bridge itself (the Node program that drives the browser) runs on the DESKTOP: Adom Bridge bundles it and auto-installs/updates it, and it's published separately on the Releases tab as adom-bridge-puppeteer-v<ver>.zip. The pkg version is kept in lockstep with the Release version so the page's max version row always carries BOTH a pkg tarball (skills) and a runtime zip (bridge) \u2014 a skills-only or runtime-only bump on the top row breaks constraint installs. TL;DR: pkg install = the skills for your AI; the bridge = the Release zip, which Adom Bridge manages for you.",   "keywords": [@@ -148,5 +148,5 @@       "prompt": "Download the puppeteer-bridge zip from the wiki and walk me through server.js"     }   ],-  "changelog": "A pup window stuck on its birth page now gets sent to its address. Testing 2.0.724 on ConfRoomROG showed the gap behind John's PUPBIRTH window: when the navigate after birth answered but the tab never left the birth page, pup recorded the birth page as the window's address, so nothing could ever send it on. The birth page is now never recorded over a real address (live tab sync, tab refresh, both open paths, and re-adoption after a restart), the open logs it, and the health check sends the window on. Includes 2.0.724."+  "changelog": "A pup window waiting on a slow page now explains itself instead of showing a blank PUPBIRTH tab: which AI thread opened it, why, where it is going, how long it has waited, and what a pup window is; after 10 s the tab and taskbar title read 'Opening <site> for <thread> (pup)' (John, 2026-10-19). AIs no longer give up with 'CDP is switched off on this box': a lane:\"cdp\" open on a box with that lane off now opens on the extension lane and says so, every hint that sent an AI to the CDP lane now names the extension-lane way, the skills say plainly that every pup window has CDP-level access, and the new pup_devtools {method, params} sends any DevTools command to a pup window through pup's extension. pup's background process queries now start PowerShell with no window, honour their timeout, and use one script file per call. Includes 2.0.725." }

@@ -4,7 +4,7 @@   "slug": "pup-bridge",   "title": "Pup - the AI's own browser",   "brief": "pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.",-  "version": "2.0.725",+  "version": "2.0.726",   "tags": [     "skills",     "pup",@@ -168,5 +168,5 @@     "Kyle Bergstedt <[email protected]>",     "Colby Knox"   ],-  "changelog": "A pup window stuck on its birth page now gets sent to its address. Testing 2.0.724 on ConfRoomROG showed the gap behind John's PUPBIRTH window: when the navigate after birth answered but the tab never left the birth page, pup recorded the birth page as the window's address, so nothing could ever send it on. The birth page is now never recorded over a real address (live tab sync, tab refresh, both open paths, and re-adoption after a restart), the open logs it, and the health check sends the window on. Includes 2.0.724."+  "changelog": "A pup window waiting on a slow page now explains itself instead of showing a blank PUPBIRTH tab: which AI thread opened it, why, where it is going, how long it has waited, and what a pup window is; after 10 s the tab and taskbar title read 'Opening <site> for <thread> (pup)' (John, 2026-10-19). AIs no longer give up with 'CDP is switched off on this box': a lane:\"cdp\" open on a box with that lane off now opens on the extension lane and says so, every hint that sent an AI to the CDP lane now names the extension-lane way, the skills say plainly that every pup window has CDP-level access, and the new pup_devtools {method, params} sends any DevTools command to a pup window through pup's extension. pup's background process queries now start PowerShell with no window, honour their timeout, and use one script file per call. Includes 2.0.725." }\ No newline at end of file

@@ -1,7 +1,7 @@ --- name: pup-lanes user-invocable: false-description: "Parent skill: pup. The two ways pup drives a pup window (never name the browser build to a user), the extension lane (DEFAULT, every vendor site loads, no debug port) and the CDP lane (opt-in ONLY via lane:'cdp', full DevTools control but detectable and walled by vendor edges). Pros and cons of each, exactly which verbs need CDP, what lane:'cdp' costs (it takes adom-you away from the extension lane and closes its windows), and the rule: never open a CDP window unless the task specifically needs a CDP-only feature. Read before passing lane, isolated, profile, highFps or webSecurity to pup_open_window, and whenever a verb answers lane_needs_cdp or cdp_lane_required. Trigger words: pup lane, extension lane, cdp lane, lane:cdp, lane_needs_cdp, cdp_lane_required, which lane, remote-debugging-port, debug port detected, site blocks pup, pup_open_window lane, isolated:true refused, highFps refused, three icons vs four icons."+description: "Parent skill: pup. The two ways pup drives a pup window (never name the browser build to a user), the extension lane (DEFAULT, every vendor site loads, no debug port) and the CDP lane (opt-in ONLY via lane:'cdp', full DevTools control but detectable and walled by vendor edges). Pros and cons of each, exactly which verbs need CDP, what lane:'cdp' costs (it takes adom-you away from the extension lane and closes its windows), and the rule: the extension lane already has CDP-level access (pup_devtools sends any DevTools command), so never stop or move a task because the CDP lane is off. Read before passing lane, isolated, profile, highFps or webSecurity to pup_open_window, and whenever a verb answers lane_needs_cdp or cdp_lane_required. Trigger words: pup lane, extension lane, cdp lane, lane:cdp, lane_needs_cdp, cdp_lane_required, which lane, remote-debugging-port, debug port detected, site blocks pup, pup_open_window lane, isolated:true refused, highFps refused, three icons vs four icons." ---  # pup lanes: the extension lane is pup. CDP is the exception.@@ -43,9 +43,9 @@ only CDP can do AND the user has turned that lane on for the box (`cdpLane`, off  1. Open windows with no `lane`. You get the extension lane. 2. `profile` and `isolated` need no lane (2.0.659: their own extension-lane browser). Only `highFps` and `webSecurity:false` still need `lane:"cdp"`; without it pup refuses with `cdp_lane_required` and says why. Since 2.0.563 nothing silently opens on CDP.-3. Pass `lane:"cdp"` only when the task needs a CDP-only feature, say which one in `reason`, expect vendor sites to wall that window, and expect `cdp_lane_disabled` unless the user enabled the lane on that box.+3. You almost never need `lane:"cdp"`: the extension lane speaks the full DevTools protocol through pup's extension, and `pup_devtools {method, params}` sends any command to an extension-lane window. Since 2.0.726, `lane:"cdp"` on a box with the CDP lane off opens on the extension lane with a `_laneNote` instead of refusing; never stop, and never move the task to another box, because CDP is off.    A pup update reaches a running extension lane on its own: pup re-stages the extension, cycles the lane browser and relaunches every window from its file on the new extension (2.0.647; the 2.0.569 in-place reload broke the channel and is gone), so a new build takes effect without anyone closing a window. `pup_status.extensionLane.workerVersion` shows what the lane is running.-4. If a verb answers `lane_needs_cdp`, first ask whether the task can be done without it (a screenshot instead of an eval on a CSP page, a URL download instead of a click). Only then reopen with `lane:"cdp"`.+4. If a verb says something is not wired on the extension lane yet, its hint names the extension-lane way (a URL download, `pup_type` for a stubborn form, `pup_devtools` for iframes and anything else). Use that, and file the gap on adom/pup-bridge.  ## How you tell them apart @@ -60,8 +60,9 @@ The toolbar: four icons is the extension lane, three is CDP (John's own spec for  ## The CDP lane is OFF by default (2.0.652, John 2026-09-19) -`pup_open_window {lane:"cdp"}` answers `cdp_lane_disabled` unless the user has turned it on for that box with-`pup_configure {cdpLane:"on"}`. John: "i want it almost NEVER used cuz then you may use it as a crutch instead of+`pup_open_window {lane:"cdp"}` opens on the extension lane (with a `_laneNote`) unless the user has turned the CDP lane+on for that box with `pup_configure {cdpLane:"on"}`; before 2.0.726 it refused with `cdp_lane_disabled`, and AIs read+that as "pup can't do this here". John: "i want it almost NEVER used cuz then you may use it as a crutch instead of fixing ext lane to solve all use cases." Trusted input, HTTP auth, fetch, screenshots and recording all run on the extension lane; a feature that genuinely needs CDP is an extension-lane gap to file on adom/pup-bridge, not a reason to open a CDP window. `isolated:true` and `profile:"<name>"` run on the extension lane too (2.0.659): each profile gets its own lane browser, its own staged extension and queue, so an isolated window is a separate browser with an empty jar, and a throwaway one ends with its last window.