Pup - the AI's own browser

@@ -100,19 +100,40 @@ kicad/fusion bridges). Adom Desktop ships a bundled seed and auto-pulls newer ve  - Clone the source: `adom-wiki repo clone adom/adom-desktop-puppeteer-bridge` - Runtime lives in `src/` (`server.js`, `chrome.js`, `bridge.json`, …); the release zip is `src/` at zip-root.-- **Developer/publishing skills** are bundled sub-skills in the wiki skillpack layout —-  `skills/pup-bridge-dev/SKILL.md` + `skills/pup-bridge-publish/SKILL.md` (`user-invocable: false`,-  clearly marked DEVELOPER-only so they never trigger for everyday users). Skill map:+- **Maintainer skills** (`pup-bridge-dev`, `pup-bridge-publish`) are **source-only** — in `dev-skills/` ++  `publish-skills/`, not shipped in the pkg (per the Bridge SDK a pkg ships only user skills). Skill map:  | Skill | Ships in pkg? | What it's for | |---|---|---| | `pup` (root SKILL.md) | ✅ user | Start here — mental model (CDP-launched fresh process of the installed browser, rendered-but-backgrounded), when-vs-extension, quick start | | `pup-windows-sessions-tabs` | ✅ user | sessionIds, window ownership (don't steal another thread's window), background-vs-foreground, many tabs in one window |-| `pup-screenshots-recording` | ✅ user | Screenshots (full-page/full-res) + recording a window vs the whole desktop |+| `pup-screenshots-recording` | ✅ user | Screenshots (full-page/full-res) + recording; driving/verifying tricky pages (shadow DOM, nested scroll) | | `pup-browsers-and-chrome` | ✅ user | Browser detection/launch, `browser_use`, installing Chrome/CfT (incl. UAC-notify), readiness, cold-start errors |+| `pup-adom-wiki` | ✅ user | Driving + verifying `wiki.adom.inc` pages in pup (view/screenshot/verify; the login situation) | | `pup-bridge-dev` / `pup-bridge-publish` | ❌ source-only | MAINTAINERS: bridge internals + the publish/release recipe (in `dev-skills/`/`publish-skills/`, not shipped) | - Ownership boundary: `CLAUDE.md`. Publish recipe: `PUBLISHING.md`. History: `CHANGELOG.md`. +## Extend pup — add your own pup skill (third parties)++Built a skill that drives pup for a specific job (a site-specific scraper, a visual test flow, a+domain widget)? You don't need write access here — surface it from this page with a **breadcrumb**:++1. **Publish your skill** to your own wiki page (see the `adom-wiki` / `wiki-skillpack` skills). Make it a+   normal user skill so `pkg install` drops it into a container's `~/.claude/skills`.+2. **Drop a breadcrumb on this page** pointing at it:+   ```bash+   adom-wiki breadcrumb post adom/adom-desktop-puppeteer-bridge \+     --label "Your skill name — one-line what it does" \+     --target-url "https://wiki.adom.inc/<owner>/<your-slug>" \+     --category "skill"+   ```+   It's **pending until the page owner approves it**, then it shows in this page's **Breadcrumbs** tab.+3. **Discovery is automatic:** an agent working with pup can list related third-party skills with+   `adom-wiki breadcrumb list adom/adom-desktop-puppeteer-bridge` — approved breadcrumbs are how pup finds+   community skills that build on it.++Keep breadcrumbs on-topic (they genuinely extend pup / browser-driving); off-topic ones get rejected.+ ## Related  - [Bridge SDK guide](https://wiki.adom.inc/adom/adom-desktop-bridges) — `bridge.json` schema, packaging, lifecycle

@@ -59,6 +59,7 @@ design; the extension is its counterpart for the real profile. | **`pup-windows-sessions-tabs`** | sessionIds + naming, **window ownership** (don't steal another AI thread's window), **background vs foreground** rules, **many tabs in one window**, list/switch/close, verifying what you opened | | **`pup-screenshots-recording`** | Screenshots (full-page, full-res), reading the shot, **recording** a window vs the whole desktop, framing a window for a clean shot without foregrounding | | **`pup-browsers-and-chrome`** | The browser detection/CDP-launch details, `browser_use` to pin a browser, **installing Chrome / Chrome-for-Testing** (incl. the UAC-notify flow), **readiness**, the cold-start error table, Node provisioning, the shell-approval gate |+| **`pup-adom-wiki`** | Driving + verifying **`wiki.adom.inc`** pages in pup (show/screenshot/verify a published page; the login situation — pup views the wiki logged out for now) |  *(Maintaining the bridge itself? The `pup-bridge-dev` + `pup-bridge-publish` skills are source-only in the repo — not shipped here.)*

@@ -17,7 +17,8 @@ deploy_into() {   install_skill pup-windows-sessions-tabs  skills/pup-windows-sessions-tabs/SKILL.md   install_skill pup-screenshots-recording  skills/pup-screenshots-recording/SKILL.md   install_skill pup-browsers-and-chrome    skills/pup-browsers-and-chrome/SKILL.md-  echo "  -> $BASE (pup + 3 sub-skills)"+  install_skill pup-adom-wiki              skills/pup-adom-wiki/SKILL.md+  echo "  -> $BASE (pup + 4 sub-skills)" }  echo "Installing adom-desktop-puppeteer-bridge skills:"

@@ -1,6 +1,6 @@ {   "slug": "adom-desktop-puppeteer-bridge",-  "version": "1.8.26",+  "version": "1.8.27",   "type": "app",   "description": "CONTAINER-SIDE install \u2014 the pup skill pack in the wiki skillpack layout: the everyday `pup` user skill PLUS two bundled developer sub-skills (pup-bridge-dev, pup-bridge-publish; user-invocable:false, DEVELOPER-only descriptions so they never trigger for everyday users), all dropped into ~/.claude/skills/ AND ~/.codex/skills/ by an explicit install.sh list. It does NOT contain the bridge runtime: the bridge (Node + browser driving) lives on the DESKTOP \u2014 bundled inside Adom Desktop and published on the Releases tab as adom-bridge-puppeteer-v<ver>.zip, which Adom Desktop streams into its bridges-cache. TL;DR: pkg install = the skill pack; the bridge = the Release zip + bundled in Adom Desktop.",   "keywords": [@@ -24,6 +24,7 @@     "skills/pup-windows-sessions-tabs/SKILL.md",     "skills/pup-screenshots-recording/SKILL.md",     "skills/pup-browsers-and-chrome/SKILL.md",+    "skills/pup-adom-wiki/SKILL.md",     "install.sh",     "uninstall.sh",     "README.md",

@@ -0,0 +1,68 @@+---+name: pup-adom-wiki+user-invocable: true+description: "Driving the Adom wiki (wiki.adom.inc) inside a pup window — the common case of loading, viewing, and VERIFYING wiki pages with the browser_* verbs. Use when the user says show me the wiki / open my wiki page in pup / verify my page rendered / check the hero/version/download card / does my published page look right. Covers: pup shows the RENDERED page (use the adom-wiki CLI for API tasks like publish/search/releases — NOT pup); wiki pages are component-heavy with nested scroll, so use the shadow-DOM-survey + scroll-the-element techniques; and the LOGIN situation — pup currently sees the wiki LOGGED OUT (auto-login from the container identity isn't supported yet; tracked in adom/wiki discussion #89), so don't claim logged-in-only content and offer auto-login only once that lands. Trigger words: adom wiki, wiki.adom.inc, show me the wiki, open the wiki in pup, open my wiki page, verify my wiki page, check my hero, wiki version chip, download card, wiki page rendered, is my page live, wiki login pup, log into the wiki."+---++**Parent skill:** adom-desktop-puppeteer-bridge  ·  See also: `pup` (start here), `pup-screenshots-recording` (the tricky-pages techniques), the `adom-wiki` skill (the CLI for API work).++# pup — driving the Adom wiki++Loading `wiki.adom.inc` pages into pup to **look at the rendered result** is one of pup's most common+jobs — confirming a page you just published looks right, a hero renders, a version chip updated, a+download card is correct. This skill is the wiki-specific playbook.++## pup VIEWS the rendered page; the `adom-wiki` CLI DOES the work++- **API / authoring tasks — use the `adom-wiki` CLI, not pup:** publishing pages, pushing files, cutting+  releases, `pkg` work, searching/discovery, discussions, breadcrumbs. These are authenticated Bearer-token+  operations the CLI already does; driving them through a browser form would be slower and fragile.+- **pup is for the rendered VIEW:** open the page, screenshot it, verify the hero/version/sections rendered,+  count cards, click through tabs. After any `adom-wiki` publish, showing the LIVE page in pup (cache-bust+  with `?v=<ver>`) is the standard "prove it shipped" step.++```bash+# Verify a page you just published (own the window, task-prefix the id):+adom-desktop browser_open_window '{"sessionId":"wiki-mypage","owner":"mypage","url":"https://wiki.adom.inc/adom/my-slug?v=1.2.3"}'+adom-desktop browser_eval        '{"sessionId":"wiki-mypage","expr":"document.title"}'   # confirm it loaded+adom-desktop browser_screenshot  '{"sessionId":"wiki-mypage"}'                            # read it — did the hero/version render?+```++Reuse **one** window per page (stable `sessionId` like `wiki-<slug>`) so re-publishes refresh the same+window instead of piling up tabs.++## Wiki pages are component-heavy — use the tricky-pages techniques++The wiki renders widgets (download cards, sample-prompt cards, the hero) and often puts content in a+**nested scroll container**. So the usual gotchas apply (full detail in `pup-screenshots-recording` →+"Driving & verifying tricky pages"):+- To find/count something (download cards, skills, files), **count in `browser_eval` by document-Y**+  (`rect.top + window.scrollY`), don't eyeball a screenshot that may have overshot.+- To screenshot a specific widget, **`el.scrollIntoView({block:'center'})`** — `window.scrollTo` does+  nothing on the wiki's inner scroll box.+- If a `querySelectorAll` comes back empty, first **survey for shadow roots** — most wiki widgets are+  plain DOM, so an empty result usually means the selector, not a shadow root.++## Login — pup sees the wiki LOGGED OUT (for now)++pup drives a **fresh, isolated browser** with no cookies, so it views the wiki **logged out** — it sees+only public content. There is currently **no supported way to auto-login pup as the container's identity**:+the wiki uses centralized Adom SSO (`hydrogen.adom.inc`), the container's token works only as an API+`Authorization: Bearer` header (not as a browser cookie), and there's no magic-link / token→session+endpoint. So:+- **Don't claim you can see logged-in-only features**, and don't offer to "log you in" today — you can't+  (and you must never drive the SSO form with the user's password).+- The clean fix — a one-time magic-link the container can mint from its own token — is **requested in+  `adom/wiki` discussion #89**. Once it ships, this skill gains an "offer + do auto-login" flow: when a+  task clearly needs logged-in features, pup can say *"I can log you into the wiki automatically — want+  me to?"* and do it with zero credentials. Until then, if a task needs a signed-in view, tell the user+  they'd need to log in themselves.++## Common wiki-in-pup tasks++- **"Show me my page in pup"** → open `https://wiki.adom.inc/<type>/<slug>?v=<ver>`, screenshot, hand over+  the link. (For the user's own machine, respect the background-by-default rule unless they said "show me.")+- **Verify a publish** → open the page, confirm the version chip + hero + your changed section rendered+  (read the screenshot; a curl 200 is NOT verification).+- **Count/verify a widget** (download cards, skills, files) → DOM-count by document-Y, then scroll the+  element in + screenshot to confirm.

@@ -5,7 +5,7 @@ set -e remove_from() {   local BASE="$1"   rm -rf "$BASE/adom-desktop-puppeteer-bridge" \-         "$BASE/pup-windows-sessions-tabs" "$BASE/pup-screenshots-recording" "$BASE/pup-browsers-and-chrome" \+         "$BASE/pup-windows-sessions-tabs" "$BASE/pup-screenshots-recording" "$BASE/pup-browsers-and-chrome" "$BASE/pup-adom-wiki" \          "$BASE/pup-bridge-dev" "$BASE/pup-bridge-publish"   echo "  <- $BASE" }