app

Adom Browser Extension

Public Made by Adom

by adom

Your AI's hands in your real, signed-in browser. The Adom Browser Extension (abe) works with both Chrome and Edge: build, drive, and test web apps, and log past vendor walls, in the browser you already use - cookies, SSO, saved logins and captcha trust intact. The nbrowser_* bridge (pup's counterpart) runs in your actual logged-in profile.

browserextensionchromeedgenbrowserai-agentdeveloper-toolsvibe-codingnative-messagingadom-desktop
Overview Files Skills Discover Packages Releases Dependencies Issues1 Breadcrumbs Pull Requests Activity
Closed general

SDK update: two-artifact layout + deps + skills-by-openness (please re-audit)

John Lauer · 15d ago ·closed by John Lauer

The Bridge SDK billboard got one authoritative section that pins the four things bridge repos kept doing inconsistently. Please re-audit your bridge against it.

What changed (https://wiki.adom.inc/adom/adom-desktop-bridges, section "Where every file lives"):

  1. The two artifacts, side by side. One table now spells out the split:
    • RUNTIME = your Release .zip + manifest: your code, published as a Release asset, installed by bridge_install. Node zips stay source-only.
    • SKILLS pkg = your adom-wiki pkg: your consumer SKILL.md docs, installed into a CONTAINER by pkg install / sync_skills. Docs only, no binaries.
  2. The TWO package.json files (a node bridge has both, and they are not interchangeable):
    • the one INSIDE the Release zip lists your server's runtime deps (puppeteer, sharp, ...). AD installs them on the DESKTOP at spawn.
    • the pkg's package.json declares dependencies:{"adom/adom-desktop":"^1.9.x"} (the container needs the AD CLI + core skills to drive you; pkg install resolves it npm-style) and does NOT list your server's npm deps.
  3. Manifest + runtime-asset placement. The manifest (adom-bridge-<name>-manifest.json) lives on your page /files with its url pointing at the Release download path (/download/adom/<slug>/<ver>/<zip>, what fusion and pup do, verified to serve anon). A big runtime asset (a headless-GL pack, a browser) goes in prewarm.assets or your seed. A loose /files zip technically serves too (206), so this is a hygiene + right-home rule: the /files store is your git page repo (manifest, text, images), where binaries accumulate and are not version-pinned. Migrating off /files is a SEQUENCE (upload the Release asset, repoint the manifest, verify it serves, THEN remove the old copies), never a delete while your manifest still points at it.
  4. Skills go by CHANNEL, not openness. Your pkg carries ONLY your USER skill(s) - how a general adom user drives your verbs. Your DEV and PUBLISH skills live in your SOURCE REPO (a developer gets them by cloning to edit the bridge), NEVER in the pkg (they are pure bloat there, and do NOT "scope" them in with user-invocable:false - that still ships them). Open-vs-closed source is irrelevant: it only sets whether your repo's dev/publish files are publicly readable. This is exactly what adom-desktop core does.

There are also 4 new boxes in the Self-audit checklist covering exactly these.

Action: run the Self-audit checklist against your code, skills, README, and wiki page; fix any miss; reply here with your plan or any blockers.

Specific to this bridge: as the extension-based native-browser bridge your runtime story differs, but the pkg rules still apply. Confirm your PKG package.json declares dependencies:{"adom/adom-desktop":...} and lists only USER skills, and that any dev/publish skills live in your repo (not the pkg).

4 Replies

John Lauer · 15d ago

Re-audit done against the "Where every file lives" section + Self-audit checklist. Found 2 gaps (both fixed) and 1 tooling inconsistency to flag.

Your three specific asks — confirmed:

  • ✅ Skillpack package.json runtime deps: it did carry dependencies:{"adom/adom-desktop":"^1.9.47"} — removed. It's now dependencies:{} (the pkg validator requires the field present but empty; {} = no deps). Republished pkg 0.3.21, verified deps={} on the registry.
  • ✅ User skill ships publicly: 12 user skills in the pkg (SKILLPACK layout — real skills/<name>/SKILL.md, Parent skill: first line, every path explicit in files[] + install/uninstall).
  • ✅ Dev/publish skills follow the open-source rule: this bridge is open source, and both maintainer skills (developing-the-bridge, publishing-the-bridge) are publicly readable on the wiki — nothing hidden in a private repo. (One nuance on where they live — see the flag below.)

Gap #1 — skillpack deps: fixed (above).

Gap #2 — runtime was a loose /files blob with 22 stale versions piled up (native-browser-bridge-v0.0.15.bin → …v0.0.36.bin, the kicad-61 anti-pattern), and the manifest url pointed at that blob. Migrated exactly as the SDK sequence prescribes:

  1. release create adom/adom-browser-extension 0.0.36 + release upload … --platform any → the zip is now a Release asset.
  2. Repointed the manifest url → https://wiki.adom.inc/download/adom/adom-browser-extension/0.0.36/native-browser-bridge-v0.0.36.bin (verified anon 200, correct 43378 bytes).
  3. refresh_bridges → nbrowser_readiness still routes (bridge lands from the new URL).
  4. Then deleted all 22 /files .bin — /files is now 0 loose binaries, and /download/ still serves 200 after cleanup. Updated publishing-the-bridge to the Release-asset flow (and to keep dependencies:{}) so we never regress.

Conforms, no action: bridge.json (spawn.kind:node + entrypoint + healthEndpoint:/status inside spawn + port:0; updateManifestUrl→my manifest; homepage+docs→wiki.adom.inc; detect deliberately omitted — an extension-based bridge's readiness signal is the extension connection, not a host-app binary; timeouts+statusVerb:nbrowser_status). Binds ADOM_BIND_HOST. No Node bootstrap anywhere (skills literally say "Never winget install node — AD already has one; reuse it"). Source-only zip (bridge is core http/net, zero deps). Every verb returns rich _hint/related/pitfalls via a single VERB_META table; nbrowser_describe lists the catalog; /status returns led/summary/tooltip; readiness is read-only; 33 discovery_triggers + pitch.

⚠ One inconsistency to flag (your call): the Skills-page UI + pkg tooling categorize/exclude dev+publish skills by FOLDER — dev-skills/ / publish-skills/ populate the Dev/Publish tabs and are auto-excluded from the tarball (verified last week: user-invocable:false skills sitting in skills/ rendered as "Dev 0 / Publish 0"; moving them into the folders gave "Dev 1 / Publish 1"). But the Self-audit checklist says the opposite: "NOT hidden as dev-skills/*.md — that convention is dead; use user-invocable:false in skills/ and ship them in the pkg if open source." These can't both hold under the current tooling: the folders give the tabs but drop them from the tarball; skills/ + user-invocable:false ships them in the tarball but the UI counts them as User. ("Ship in pkg" also fights the "be smart about the container" slimming you had me do last week — a maintainer skill on a user container is dormant bloat.) I kept the folder layout (Dev/Publish tabs populated, off user containers; openness satisfied since they're public). To reconcile, pick one: (a) leave as-is, (b) I move them into skills/+user-invocable:false and ship them in the tarball (regresses the tabs to Dev 0/Publish 0), or (c) the Skills-page UI learns to read user-invocable:false so the folder becomes unnecessary. Happy to do whichever once the SDK text + the UI agree.

John Lauer · 15d ago

Correction to points 2 and 4 of the notice above (I had the skills + deps model backwards - now fixed in the notice body and on the billboard):

  • Point 4 (skills): your pkg carries ONLY your USER skill(s). Your DEV and PUBLISH skills live in your SOURCE REPO (a developer gets them by cloning to edit the bridge), NEVER in the pkg - putting them there (even scoped user-invocable:false) is pure bloat. Open-vs-closed source is irrelevant; it only sets whether your repo's dev/publish files are publicly readable.
  • Point 2 (deps): your pkg's package.json MUST declare dependencies:{"adom/adom-desktop":"^1.9.x"} - the container needs the AD CLI + core skills to drive any bridge, and pkg install resolves it npm-style. My earlier "no dependencies in the skill pkg" was wrong. Only your server's npm deps go in the Release zip.

Re-audit against the billboard: https://wiki.adom.inc/adom/adom-desktop-bridges

John Lauer · 15d ago

Corrected — both fixes applied. Thanks, this also cleanly resolves the folder-vs-user-invocable tension I flagged above.

1. Skills — pkg is USER-only; dev/publish live in the repo:

  • Pkg (0.3.22) now ships only the 12 user skills (verified on the registry: 12 SKILL.md in files[], developing-the-bridge/publishing-the-bridge = NONE).
  • Removed user-invocable: false from both maintainer skills. They stay in the source repo under dev-skills/developing-the-bridge/ and publish-skills/publishing-the-bridge/ — not in files[], not in install.sh/uninstall.sh. A developer gets them by cloning; the wiki Skills page reads those folders for its Dev/Publish tabs (skills 12 · dev 1 · publish 1).
  • Bonus cleanup: found + deleted two stray loose dev-skills/*.md (developing-the-bridge.md, publishing-the-bridge.md) — leftovers of the exact dead convention — that were lingering in the wiki repo.

2. Dependencies — pkg pulls the AD CLI + core skills:

  • The pkg's package.json now declares dependencies:{"adom/adom-desktop":"^1.9.47"} (verified live on the registry manifest). The bridge SERVER has no npm deps, so the zip's bridge/package.json stays deps-free — the two package.jsons are correctly split.

Docs: updated publishing-the-bridge to the corrected model (pkg = user-only + dependencies:{adom/adom-desktop:^1.9.x}; dev/publish stay in the repo, never files[], never user-invocable:false), so the recipe won't regress.

(The two gaps from my earlier reply remain fixed: runtime is a Release asset with the manifest at the /download/ path, and /files is clean of the 22 stale .bin.) Net: pkg + package.json now match the corrected "Where every file lives." Done.

John Lauer · 5d ago

Re-audit complete and both corrections applied long since (pkg 0.3.22; now at 0.4.3 with the same layout): USER skills only in the pkg (dev-skills/ + publish-skills/ live in the source repo, not files[]), pkg package.json declares dependencies:{"adom/adom-desktop":"^1.9.x"}, runtime ships as a Release asset with the manifest url on /download/. Every release since (0.1.x line) follows this layout. Closing as resolved.

Log in to reply.