Pup - the AI's own browser

@@ -1,11 +1,20 @@ --- 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). pup drives Chrome for Testing (the automation build: no automation banner, deterministic version, toolbar extension rides the launch, see docs/WHY-CFT.md; installed Chrome/Edge are fallbacks) in a pup-managed DURABLE profile (logins/localStorage persist and are shared across pup windows; {isolated:true} for a throwaway), driven through pup's own extension channel with NO --remote-debugging-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's the Adom extension's nbrowser_* verbs), NOT headless (a real rendered window, so screenshots/recording are true-to-life). Chrome for Testing only as a last resort. 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 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." ---  # Pup: browser control on the user's desktop (start here) +## What to call it when you talk to the user++They are **pup windows**. Say "I opened it in pup" or "your pup window". Do not tell the user what+browser build pup runs, that its windows are titled "Google Chrome for Testing", or how pup drives+them, unless they ask directly (pup-bridge#114, 2026-09-14: an AI kept narrating "Chrome for Testing+windows" while opening pup windows, and John's direction is that pup downplays how it does its+magic). The build detail lives in the maintainer skills (pup-why-cft, pup-browsers-and-chrome) for+when a user asks; it is not part of a normal answer.+ Drive a browser on the user's desktop from a cloud container via the `adom-bridge-cli` CLI. Every verb is a **Bash command** (NOT an MCP tool): 

@@ -1,6 +1,6 @@ {   "slug": "pup-bridge",-  "version": "2.0.571",+  "version": "2.0.572",   "type": "app",   "description": "The pup SKILL PACK \u2014 the AI skills that teach a cloud/container AI how to drive the Adom Desktop Puppeteer (pup) bridge (browser_* 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 Desktop 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 Desktop manages for you.",   "keywords": [@@ -148,5 +148,5 @@       "prompt": "Download the puppeteer-bridge zip from the wiki and walk me through server.js"     }   ],-  "changelog": "Skills describe what shipped on 2026-09-14: the thread tile and the overlay badge are composed in the binary (pup-taskbar-states); annotate works on both lanes and the CDP-only list shrinks accordingly, plus the worker self-reload note (pup-lanes, pup-settings); the extension lane's architecture for maintainers, from the shared birth watcher to the queued channel (pup-bridge-dev). The last 41 em-dashes are gone from pup-settings and pup-taskbar-states. No code change from 2.0.570."+  "changelog": "pup-bridge#114: users hear 'pup window'. A naming rule at the top of the root skill (never name the browser build or how pup drives it unless asked), the build taken out of the frontmatter descriptions of pup, pup-lanes, pup-browsers-and-chrome and pup-why-cft (the last two are marked maintainer detail), and plain mode described as the browser's own stock button. Skills only, no code change from 2.0.571." }

@@ -4,7 +4,7 @@   "slug": "pup-bridge",   "title": "Pup - Puppeteer Bridge",   "brief": "pup is the AI's own browser: a real, full Chrome on the user's desktop that the AI fully controls (a sandbox, not the user's signed-in browser). Rides Bridge; pup_* verbs open windows and tabs, navigate, screenshot, and eval JS.",-  "version": "2.0.571",+  "version": "2.0.572",   "tags": [     "skills",     "pup",@@ -168,5 +168,5 @@       "pup-bridge verbs are invoked through the adom-bridge CLI, not through a binary this package installs, so prefix rules cannot reach them."     ]   },-  "changelog": "Skills describe what shipped on 2026-09-14: the thread tile and the overlay badge are composed in the binary (pup-taskbar-states); annotate works on both lanes and the CDP-only list shrinks accordingly, plus the worker self-reload note (pup-lanes, pup-settings); the extension lane's architecture for maintainers, from the shared birth watcher to the queued channel (pup-bridge-dev). The last 41 em-dashes are gone from pup-settings and pup-taskbar-states. No code change from 2.0.570."+  "changelog": "pup-bridge#114: users hear 'pup window'. A naming rule at the top of the root skill (never name the browser build or how pup drives it unless asked), the build taken out of the frontmatter descriptions of pup, pup-lanes, pup-browsers-and-chrome and pup-why-cft (the last two are marked maintainer detail), and plain mode described as the browser's own stock button. Skills only, no code change from 2.0.571." }\ No newline at end of file

@@ -1,7 +1,7 @@ --- name: pup-browsers-and-chrome user-invocable: true-description: "How pup (Puppeteer bridge) picks and launches a browser, and every cold-start / readiness case. Covers: the installed-browser-first architecture (launches a FRESH CDP-driven process of installed Chrome → else Edge → else cached Chrome for Testing, spawn-verified with fallthrough, caches the winner as default); pup_use to pin chrome/edge/cft/auto; INSTALLING real Google Chrome on an Edge-only box (pup_use install:true) including the UAC-approval-notify flow on locked-down machines; installing/prewarming Chrome for Testing; pup_readiness (READ-ONLY — the right 'is it ready / which browser' probe, NOT pup_status); the cold-start error table (node_not_found, bridge_restarting, chrome_for_testing_installing, chrome_install_no_disk, CfT 'skipped' is not a failure); AD-managed Node provisioning (no install needed on AD >=1.9.63); and the shell-approval gate. Read on any browser-pick question, a fresh/first-run PC, an install/prewarm, a not-ready error, or a shell-approval prompt. Trigger words: pup_readiness, pup_use, pup_prewarm, chrome for testing, install chrome, chrome_for_testing_installing, node_not_found, bridge_restarting, chrome_install_no_disk, cold start pup, which browser, edge only box, UAC approve chrome, request_shell_approval, shell command approval, adom runtimes, pup not ready."+description: "MAINTAINER detail, not for a user's ears: how pup picks and launches its browser, and every cold-start / readiness case. A user hears 'pup window'; the build behind it (installed Chrome, Edge, or pup's own automation build) is answered only when asked (pup-bridge#114). Covers: the installed-browser-first architecture (launches a FRESH CDP-driven process of installed Chrome → else Edge → else cached Chrome for Testing, spawn-verified with fallthrough, caches the winner as default); pup_use to pin chrome/edge/cft/auto; INSTALLING real Google Chrome on an Edge-only box (pup_use install:true) including the UAC-approval-notify flow on locked-down machines; installing/prewarming Chrome for Testing; pup_readiness (READ-ONLY — the right 'is it ready / which browser' probe, NOT pup_status); the cold-start error table (node_not_found, bridge_restarting, chrome_for_testing_installing, chrome_install_no_disk, CfT 'skipped' is not a failure); AD-managed Node provisioning (no install needed on AD >=1.9.63); and the shell-approval gate. Read on any browser-pick question, a fresh/first-run PC, an install/prewarm, a not-ready error, or a shell-approval prompt. Trigger words: pup_readiness, pup_use, pup_prewarm, chrome for testing, install chrome, chrome_for_testing_installing, node_not_found, bridge_restarting, chrome_install_no_disk, cold start pup, which browser, edge only box, UAC approve chrome, request_shell_approval, shell command approval, adom runtimes, pup not ready." ---  **Parent skill:** pup-bridge  ·  See also: `pup` (start here), `pup-windows-sessions-tabs`, `pup-screenshots-recording`.

@@ -1,7 +1,7 @@ --- name: pup-lanes user-invocable: false-description: "Parent skill: pup. The two ways pup drives a Chrome for Testing window, 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: 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." ---  # pup lanes: the extension lane is pup. CDP is the exception.

@@ -20,7 +20,7 @@ Taskbar identity is a LADDER of three alternate modes, picked with ONE key (v2.0  | Key | Default | What it does | |---|---|---|-| `taskbarMode` | **tiles** | The identity ladder. `tiles` = ONE button per AI thread, its icon the thread NAME on the Adom teal tile (name bottom-left, big font, truncated not shrunk; all the thread's windows group under it; button title = thread name). `aumid` = one button per WINDOW with pup/category icons. `plain` = no branding at all, windows stack under the stock Chrome-for-Testing button. Maps onto `aumidIcons`+`threadTiles` underneath, so those older keys still work. |+| `taskbarMode` | **tiles** | The identity ladder. `tiles` = ONE button per AI thread, its icon the thread NAME on the Adom teal tile (name bottom-left, big font, truncated not shrunk; all the thread's windows group under it; button title = thread name). `aumid` = one button per WINDOW with pup/category icons. `plain` = no branding at all, windows stack under the browser's own stock button. Maps onto `aumidIcons`+`threadTiles` underneath, so those older keys still work. | | `taskbarGrouping` | **split** | aumid mode only: `split` = one button per window; `grouped` = group by category. | | `aumidIconStyle` | **category** | aumid mode only: `standard` = one pup tile for every window; `category` = per-kind tiles (wiki signed-in/out, open web, Adom app, mixed). | | `overlayBadges` | **on** | ORTHOGONAL to the ladder: paint the active tab's favicon badge on each button (tiles and aumid modes). No Adom mark on the badge since v2.0.192, the tile itself carries Adom identity; only the GENERIC fallback glyph (faviconless page) still includes the mark. |

@@ -29,7 +29,7 @@ preview is DERIVED from the same sources listed here, so preview and reality can | 2 | **tiles** | Same grouping as 1 | Same name tile | None, clean tile | | 3 | **aumid + overlay** | One button PER WINDOW (split) or per category (grouped) | The registered pup/category icon: wiki signed-in padlock, public wiki book, open-web globe, Adom app mark, mixed (`pup-cat-*.ico`, style/grouping set by `aumidIconStyle` + `taskbarGrouping`) | Same favicon badge per window | | 4 | **aumid** | Same as 3 | Same category icons | None |-| 5 | **plain + overlay** | ALL pup windows stack under the STOCK Chrome-for-Testing button, no pup identity anywhere | Chrome-for-Testing's own exe icon, untouched | Favicon badge only signal |+| 5 | **plain + overlay** | ALL pup windows stack under the browser's own stock button, no pup identity anywhere | Chrome-for-Testing's own exe icon, untouched | Favicon badge only signal | | 6 | **plain** | Same stacking as 5 | Same stock icon | None, indistinguishable from an unautomated browser |  ## Where every pixel comes from (and how the preview stays honest)@@ -109,7 +109,7 @@ it has not applied. ## Measured limits (2026-09-05, arav-rog, Windows 11 25H2 build 26200.9168), pup-bridge#99  - **Some Windows 11 builds draw NO taskbar progress fill, for any app.** On this build `pup_progress`-  (30/50/75%, indeterminate, error), ab `desktop_taskbar` on a stock Chrome for Testing button and on+  (30/50/75%, indeterminate, error), ab `desktop_taskbar` on the browser's own stock button and on   Notepad, and a plain PowerShell `ITaskbarList3` COM call on Notepad all reported success and painted   nothing. So never promise the pixels in a demo or a caption: say the verb ran, and if the user must SEE   it, screenshot the taskbar and read it before claiming a bar is there.

@@ -1,7 +1,7 @@ --- name: pup-why-cft user-invocable: true-description: "Parent skill: pup. WHY pup drives Chrome for Testing instead of installed Chrome/Edge, the five dated reasons (automation banner, --load-extension removal being the forcing one, version determinism, none of the consumer chrome, binary isolation), the honest trade-offs (~160 MB first fetch, the window title, no Widevine), and what did NOT change (profiles/logins are pup-owned either way). The policy flipped twice; docs/WHY-CFT.md on the wiki page is the dated canonical record and this skill is its AI-discoverable form. Read before questioning the browser choice, proposing native-first, or explaining a 'Google Chrome for Testing' window title to a user. Trigger words: why chrome for testing, why CfT, why not real chrome, why not installed chrome, why not edge, chrome for testing reasons, automation banner, controlled by automated test software, load-extension removed, browser policy pup, native-first, cft vs chrome, what is chrome for testing, google chrome for testing in task manager, widevine pup, drm pup."+description: "Parent skill: pup. MAINTAINER detail (a user hears 'pup window'; do not volunteer the build, pup-bridge#114): WHY pup drives its own automation build of Chrome instead of installed Chrome/Edge, the five dated reasons (automation banner, --load-extension removal being the forcing one, version determinism, none of the consumer chrome, binary isolation), the honest trade-offs (~160 MB first fetch, the window title, no Widevine), and what did NOT change (profiles/logins are pup-owned either way). The policy flipped twice; docs/WHY-CFT.md on the wiki page is the dated canonical record and this skill is its AI-discoverable form. Read before questioning the browser choice, proposing native-first, or explaining a 'Google Chrome for Testing' window title to a user. Trigger words: why chrome for testing, why CfT, why not real chrome, why not installed chrome, why not edge, chrome for testing reasons, automation banner, controlled by automated test software, load-extension removed, browser policy pup, native-first, cft vs chrome, what is chrome for testing, google chrome for testing in task manager, widevine pup, drm pup." ---  # Why pup drives Chrome for Testing (the five reasons)