NB - Native Browser Bridge

@@ -1,7 +1,6 @@ --- name: developing-the-bridge description: "DEVELOPER skill for maintainers of the adom-browser-extension (native-browser) bridge - NOT for driving it. Read this before editing bridge/server.js, host/native-host.js, or extension/. Covers the architecture (bridge + native-messaging host + MV3 extension, and how AD provisions Node), the #1 rule that every nbrowser_* verb must return rich _hint/_next/related/pitfalls via the VERB_META table, the verb contract, local testing, the AD-vs-bridge boundary, hard-won runtime gotchas (chrome.tabs.goBack fails on debugger-driven tabs; UIA Invoke fails on Win32 dialogs), and the safety invariants. Everyday users never need this."-user-invocable: false --- Parent skill: **adom-browser-extension**. This is a maintainer-only skill (not user-invocable). Bridge SDK: https://wiki.adom.inc/adom/adom-desktop-bridges

@@ -1,6 +1,6 @@ {   "slug": "adom-browser-extension",-  "version": "0.3.21",+  "version": "0.3.22",   "type": "app",   "title": "Adom Native Browser Extension (Chrome + Edge)",   "description": "Drive your real, logged-in Chrome/Edge from the Adom ecosystem: the nbrowser_* native-browser bridge (counterpart to pup). Multi-profile driving, a read-only credential-library query over the browser's own saved logins (Chrome + Edge), and hands-free vendor login automation, so chip CAD / datasheets download past every login wall in your real signed-in session.",@@ -28,7 +28,9 @@     "install": "./install.sh",     "uninstall": "./uninstall.sh"   },-  "dependencies": {},+  "dependencies": {+    "adom/adom-desktop": "^1.9.47"+  },   "tags": [     "browser",     "extension",

@@ -1,7 +1,6 @@ --- name: publishing-the-bridge-description: "PUBLISH skill for maintainers of the adom-browser-extension (native-browser) bridge - NOT for driving it. The exact, proven recipe to cut a release: bump versions in lockstep, build the zip, publish it as a Release ASSET (release create + upload --platform any), point the manifest url at the /download/ path (never a /files blob), push source, and land it with refresh_bridges. Covers the two-artifact split (Release zip vs skills pkg), the skillpack package.json carrying dependencies:{} (empty, no runtime deps), the bridge.json contracts we declare (timeouts) and one we deliberately don't (detect), and the standing show-in-pup rule. Everyday users never need this."-user-invocable: false+description: "PUBLISH skill for maintainers of the adom-browser-extension (native-browser) bridge - NOT for driving it. The exact, proven recipe to cut a release: bump versions in lockstep, build the zip, publish it as a Release ASSET (release create + upload --platform any), point the manifest url at the /download/ path (never a /files blob), push source, and land it with refresh_bridges. Covers the two-artifact split (Release zip vs skills pkg), the pkg's package.json declaring dependencies:{adom/adom-desktop:^1.9.x} (so pkg install pulls the AD CLI + core skills), the pkg shipping ONLY user skills while dev/publish skills live in the source repo (not the pkg, not files[], not user-invocable:false), the bridge.json contracts we declare (timeouts) and one we deliberately don't (detect), and the standing show-in-pup rule. Everyday users never need this." --- Parent skill: **adom-browser-extension**. Maintainer-only skill (not user-invocable). Bridge SDK: https://wiki.adom.inc/adom/adom-desktop-bridges@@ -60,8 +59,10 @@ Deps: none (core `http`/`net`), so the payload is source-only (no `node_modules` 7. **NEVER `repo rm` a runtime zip while the manifest still points at it.** The old `/files` `.bin` uploads    are the dead anti-pattern (they piled up to 22 stale versions once) — do NOT re-add them. If any linger,    migrate as a SEQUENCE: release-upload → repoint manifest → verify `/download/` serves → THEN delete the-   `/files` copies. The skillpack `package.json` (the pkg, not the zip) must carry `dependencies:{}` — the-   validator requires the field but it MUST be empty (no runtime deps land on a container).+   `/files` copies. The **pkg's** `package.json` (the skills tarball, not the zip) declares+   `dependencies:{"adom/adom-desktop":"^1.9.x"}` (so `pkg install` pulls the AD CLI + core skills the+   container needs) — NOT the server's npm deps (the bridge has none anyway). The **zip's**+   `bridge/package.json` holds the server's runtime deps (none for us — core `http`/`net`).  ## Reaping is fixed (AD v1.9.76) — the old orphan trap is gone Earlier, `refresh_bridges` could leave a stale PID serving old code (a node bridge doesn't lock the@@ -72,14 +73,22 @@ directly. So: after a release, just `refresh_bridges` (or `restart_bridge` for a confirm `liveVersion` matches — no more digging in `host.json` or manual `taskkill`. (`bridge_pause`/`bridge_resume` are a ROUTING gate only; they never kill the process.) -## Publish the SKILLS pkg — the SKILLPACK layout (the old dev-skills/ rule is DEAD)-`adom-wiki pkg publish --org adom`. **Every skill — user, dev, AND publish — is a real-`skills/<name>/SKILL.md`.** Scope dev/publish skills by AUDIENCE, not filename: frontmatter-`user-invocable: false` + a description that opens "DEVELOPER skill for maintainers…" so everyday users-are never offered them while maintainers still install the full set. List **every** skill path-EXPLICITLY (no globs) in `package.json` `files[]` AND `install.sh`/`uninstall.sh`. Deploy to BOTH-`~/.claude/skills` and `~/.codex/skills`. (The old "hide dev docs as `dev-skills/*.md` so they don't-ship" rule is dead as of the 2026-07-03 SDK update; pup migrated to this layout too.)+## Publish the SKILLS pkg — USER skills ONLY (dev/publish live in the repo)+`adom-wiki pkg publish --org adom`. **The pkg ships ONLY your USER skills** — the ones a general Adom+user's agent needs to DRIVE the bridge. That's the pkg's whole job: a container `pkg install`s it to USE+you. Each is a real `skills/<name>/SKILL.md` with a `Parent skill:` first line; list **every user-skill+path EXPLICITLY** (no globs) in `package.json` `files[]` AND `install.sh`/`uninstall.sh`.+- **DEV + PUBLISH skills do NOT go in the pkg — they live in your source REPO** (this skill, and+  `developing-the-bridge`). A developer who clones the source to EDIT the bridge gets them as repo files;+  the normal user never needs them. So: **not in `files[]`, not in `install.sh`, and do NOT scope them+  with `user-invocable:false`** — that convention still SHIPS them and bloats every container install.+  Keep them under `dev-skills/` + `publish-skills/` in the repo (the wiki Skills page reads those folders+  for its Dev/Publish tabs). **Open-vs-closed source is irrelevant** — it only sets whether the repo is+  publicly readable; either way dev/publish stay in the repo, never the pkg. (adom-desktop core does+  exactly this: its RELEASE/WIKI_PUBLISH/SIGNING skills live only in source, never in the published pkg.)+- **The pkg's `package.json` declares `dependencies:{"adom/adom-desktop":"^1.9.x"}`** — `pkg install`+  resolves it npm-style, so installing our skill pkg also pulls the AD CLI + core skills the container+  needs to drive us. (Do NOT put the SERVER's npm deps here — those ride in the zip's `bridge/package.json`.)  ## Discovery Edit `page.json` `discovery_triggers` (30+ user-task phrasings, login/forms niche — pup can't do