← Commit history

pup: use pup instead of headless Chrome (description + triggers)

John Lauer ·53a50504ba ·1mo ago ·parent 1962bc1
1 file changed +1−1
SKILL.md+1−1
@@ -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 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). USE PUP INSTEAD OF HEADLESS CHROME: never launch puppeteer-core, Playwright or a headless Chromium in the container to screenshot, render or check a page (John, 2026-10-06): the container's software GPU renders WebGL slowly and crashes on 3D pages, while pup has the desktop's real GPU and reaches container servers through the Hydrogen proxy (http://<port>.localhost:<proxy port>/, from $VSCODE_PROXY_URI). 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, headless chrome, headless chromium, headless browser, puppeteer-core, playwright, screenshot a web page, screenshot my page, render a page, render the 3D view, check a page renders, webgl screenshot, 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)