bootstrap
Adom Hydrogen (platform base)
Public Made by Adomby adom
Layer Hydrogen's workspace onto a standard Adom workstation.
← Commit history
Publish 0.3.1
27 files changed
+255−278
README.md+46−66package.json+4−5page.json+4−5skills/hydrogen-adom-auth/SKILL.md+1−1skills/hydrogen-adom-desktop/SKILL.md+36−36skills/hydrogen-adom-menu/SKILL.md+7−8skills/hydrogen-api/SKILL.md+4−4skills/hydrogen-bridges/SKILL.md+57−57skills/hydrogen-captions/SKILL.md+3−3skills/hydrogen-capture-share/SKILL.md+1−1skills/hydrogen-container/SKILL.md+25−25skills/hydrogen-desktop-sse/SKILL.md+4−4skills/hydrogen-eda-discovery/SKILL.md+9−9skills/hydrogen-eval/SKILL.md+1−1skills/hydrogen-instapcb/SKILL.md+4−4skills/hydrogen-notifications/SKILL.md+6−6skills/hydrogen-open-url/SKILL.md+3−3skills/hydrogen-overview/SKILL.md+8−8skills/hydrogen-permissions/SKILL.md+2−2skills/hydrogen-self-update/SKILL.md+3−3skills/hydrogen-settings/SKILL.md+7−7skills/hydrogen-setup-steps/SKILL.md+5−5skills/hydrogen-setup/SKILL.md+5−5skills/hydrogen-ui/SKILL.md+4−4skills/hydrogen-who-am-i/SKILL.md+3−3skills/hydrogen-workspace-monitoring/SKILL.md+1−1skills/hydrogen-workspace-updater/SKILL.md+2−2README.md+46−66@@ -1,33 +1,34 @@ # adom/hydrogen-bootstrap -Hydrogen Desktop's workspace layer, as an adompkg bootstrap. It's a thin-package: a dependency list + one config hook. Installing it converges a-workspace to "ready to run inside Hydrogen Desktop."+Hydrogen's platform-generic workspace layer, as an adompkg bootstrap. It's a+thin package: a dependency list, the bundled hydrogen-* skills, and one config+hook. Installing it converges a workspace to "ready to run inside Hydrogen." ``` adompkg install adom/hydrogen-bootstrap ``` -The golden WSL2 image runs exactly that line at bake time and ships the-result pre-converged. A live workspace can run the same line on demand. The-bake is an optimization of the runtime flow, not a different mechanism.+The golden image runs exactly that line at bake time and ships the result+pre-converged. A live workspace can run the same line on demand. The bake is+an optimization of the runtime flow, not a different mechanism. ## How it layers -`adom/hydrogen-bootstrap` depends on `adom/core` and adds only what's specific to-running inside HD. Layering is not a special feature — a layer is just a-bootstrap that depends on the one below it. `core` is pulled unmodified.+`adom/hydrogen-bootstrap` depends on `adom/core` and adds only what's specific+to running inside Hydrogen. Layering is not a special feature: a layer is just+a bootstrap that depends on the one below it. `core` is pulled unmodified. ```-adom/core ← the Adom ecosystem (shared with web Hydrogen)- └─ adom/hydrogen-bootstrap ← THIS: HD-runtime skills + daemon + HD editor config+adom/core ← the Adom ecosystem (shared with Hydrogen Cloud)+ └─ adom/hydrogen-bootstrap ← THIS: Hydrogen runtime skills + editor config ``` -This is the public **reference design**: other orgs build their own bootstrap-the same way. A vendor publishes `<org>/bootstrap` depending on `adom/core`-(plus `adom/hydrogen-bootstrap` only if their capability needs HD's runtime), and-their users get set up by telling their AI "I use <org>." See-[../BOOTSTRAP-CONVENTION.md](../BOOTSTRAP-CONVENTION.md) for the naming ++Platform layers depend on this one: `adom/hydrogen-windows-bootstrap` (WSL2)+and `adom/hydrogen-mac-bootstrap` (Lima). This is also the public **reference+design**: a vendor publishes `<org>/bootstrap` depending on `adom/core` (plus+`adom/hydrogen-bootstrap` only if their capability needs Hydrogen's runtime),+and their users get set up by telling their AI "I use <org>." See+[../BOOTSTRAP-CONVENTION.md](../BOOTSTRAP-CONVENTION.md) for the naming and layering convention. ## What's a dependency vs. what's in the hook@@ -36,25 +37,17 @@ The rule: **anything that is a package is a dependency; environment config that isn't a package is the `postinstall` hook; the OS baseline is the golden image's Dockerfile (not this package at all).** -### Dependencies — all three resolve anonymously (verified 2026-06-19)+### Dependencies (all resolve anonymously, sudo-free) -| Dep | Why it's here | Status |-|-----|---------------|--------|-| `adom/core` | The whole Adom ecosystem — skills hub, distributor search, KiCad/Fusion, pup, `adom-cli`, the `adom-vscode` binary, `adompkg`, etc. Replaces what gallia used to bake. | ✅ published 4.9.1, anon + sudo-free |-| `adom/adom-workspace-updater` | The in-distro updater daemon (systemd .service/.timer). | ✅ published 0.1.11, anon — **`needs_sudo: true`** |-| `adom/adom-desktop` | The Adom Desktop relay CLI. | ✅ published 1.8.147, anon |+| Dep | Why it's here |+|-----|---------------|+| `adom/core` | The whole Adom ecosystem: skills hub, distributor search, KiCad/Fusion, pup, `adom-cli`, the `adom-vscode` binary, `adompkg`. |+| `adom/adom-bridge` | Adom Bridge: the `adom-bridge-cli` verb CLI and the relay that reaches the user's desktop. | -> The `hd-*` skills are **bundled into this package** (the `skills/` dir), not a-> dependency — they're HD-specific with no independent lifecycle. The three-> ecosystem CLIs (`adom-google`, `adom-tts`, `adom-gchat`) are **inherited via-> `adom/core`** once added there (they resolve anonymously and are sudo-free) —-> HD does not carry ecosystem apps directly.--> **⚠ Installing this package requires `--allow-sudo`.** `adom/adom-workspace-updater`-> is `needs_sudo: true` (it writes systemd units), and adompkg refuses a sudo-> install script without an explicit opt-in — passwordless sudo alone is NOT-> enough. The bake (and any live install) must run:-> `ADOMPKG_ALLOW_SUDO=1 adompkg install adom/hydrogen-bootstrap`.+> The `hydrogen-*` skills are **bundled into this package** (the `skills/`+> dir), not a dependency; they're Hydrogen-specific with no independent+> lifecycle. Ecosystem CLIs (`adom-google`, `adom-tts`, `adom-gchat`) are+> inherited via `adom/core`. ### postinstall.sh (deploy bundled skills + environment config) @@ -62,11 +55,11 @@ Runs as the workspace user after all deps install (`sudo` only for the system-owned workbench file). Mirrors the config sections of `hd-wsl2-image/image/bake-hydrogen-setup.sh`: -0. Deploy the bundled `hd-*` skills (`skills/` dir → `~/.claude/skills/`)+0. Deploy the bundled `hydrogen-*` skills (`skills/` dir → `~/.claude/skills/`) 1. Claude Code CLI (claude.ai installer → `~/.local/bin/claude`) 2. Claude Code extension (Open VSX) registered in code-server 3. `adom-vscode` extension `.vsix` registered in code-server (binary from the `core` dep)-4. code-server `settings.json` (dark theme, Claude Code perms, chat/agent panel off, silent ports — no model pin)+4. code-server `settings.json` (dark theme, Claude Code perms, chat/agent panel off, silent ports, no model pin) 5. code-server `config.yaml` (telemetry + update-check off) 6. `workbench.html` IndexedDB seed (trusted domains `*` + activity-bar unpin) 7. tidy (`rm ~/project/.mcp.json`)@@ -77,37 +70,24 @@ apt baseline, code-server, systemd/systemd-sysv, cron, the gh CLI, user/group/linger/pam fixes. The "hardware" the bootstrap runs on. A live install assumes a workspace that already has it. -### NOT in this package (per-machine, injected by HD at `wsl --import`)+### NOT in this package (per-machine, injected by Hydrogen at import) The Carbon API key, `DefaultUid=1001`, the `host.docker.internal` alias. -## Open decisions / remaining work--- ✅ **Skills bundled into `skills/`** — the **31 platform-generic** `hd-*` skills.- The other 15 are Windows-specific (in `adom/hydrogen-windows-bootstrap`); 13 mixed- skills were split, generic core here + a `<name>-windows` companion in the- Windows layer. Decided: bundled, not a separate `adom/hd-skills` package.-- **InstaPCB:** the generic bundle **includes `hydrogen-instapcb`** (and `hydrogen-who-am-i`'s- InstaPCB lines). This package is published **public WITH InstaPCB included** —- an explicit owner decision (2026-06-19) overriding the general InstaPCB embargo- for this package, so the launch can be planned against the real thing.-- **Edit `adom/core` to add `adom-google` / `adom-tts` / `adom-gchat`** so HD- inherits them (all three verified anon + sudo-free). Needs core's source- (wiki-git) + a republish.-- **Skill-vs-binary completeness in core:** core deps the distributor *skills*- (`adom/mouser`…), not the *binaries* (`adom/adom-mouser`…). Confirm whether- the skills just drive `adom-cli` (in core) — decides whether the Dockerfile- still bakes the distributor binaries.--## Status (2026-06-19)--**PUBLISHED + PUBLIC** at `adom/[email protected]` on wiki.adom.inc. Deps-resolve anonymously; the `adom/core` contract is **green** (anonymous +-sudo-free across the whole tree). Install requires `ADOMPKG_ALLOW_SUDO=1` (the-Windows layer's updater dep is `needs_sudo`). The golden-image bake-(`bake-via-bootstrap.sh`) installs `adom/hydrogen-windows-bootstrap`, which pulls this-+ `adom/core`. **Open blocker for the bake:** `adom/[email protected]`-(a transitive dep of `adom/core`) currently FAILS signature verification —-Colby must republish it before any `adompkg install adom/core` (and thus the-bake) can complete. Build the image on the laptop via AD or in CI, never in the-cloud container.+## Notes++- The bundled set is the **platform-generic** `hydrogen-*` skills; the+ Windows-specific ones live in `adom/hydrogen-windows-bootstrap`, the mac ones+ in `adom/hydrogen-mac-bootstrap`. Mixed skills were split: generic core here,+ a platform companion in the platform layer.+- The generic bundle **includes `hydrogen-instapcb`** (and `hydrogen-who-am-i`'s+ InstaPCB lines): an explicit owner decision (2026-06-19) overriding the+ general InstaPCB embargo for this package.++## Status (2026-08-08)++**PUBLISHED + PUBLIC** on wiki.adom.inc as part of the 2026-08 naming cutover+(formerly `adom/hd-bootstrap`). Deps resolve anonymously and the whole tree is+sudo-free (`needs_sudo: false`; the retired updater daemon was the only sudo+dependency). Build the golden image on the laptop via Adom Bridge or in CI,+never in the cloud container.
package.json+4−5@@ -3,15 +3,14 @@ "slug": "hydrogen-bootstrap", "type": "bootstrap", "title": "Adom Hydrogen (platform base)",- "brief": "Layer Hydrogen Desktop's workspace onto a standard Adom workstation.",- "version": "0.3.0",- "description": "Hydrogen Desktop's PLATFORM-GENERIC workspace layer on top of adom/core. Installs adom/core for the full Adom ecosystem, then adds everything common to running inside Hydrogen Desktop on ANY platform: the runtime-neutral hd-* skills and the generic HD editor configuration (Claude Code CLI + extension, VS Code settings, trusted domains). Platform-specific layers depend on THIS: adom/hd-windows-bootstrap (WSL2), adom/hd-mac-bootstrap, adom/hd-ubuntu-bootstrap. The reference design other orgs copy to build their own bootstrap on adom/core.",+ "brief": "Layer Hydrogen's workspace onto a standard Adom workstation.",+ "version": "0.3.1",+ "description": "Hydrogen's PLATFORM-GENERIC workspace layer on top of adom/core. Installs adom/core for the full Adom ecosystem, then adds everything common to running inside Hydrogen on ANY platform: the runtime-neutral hydrogen-* skills and the generic editor configuration (Claude Code CLI + extension, VS Code settings, trusted domains). Platform-specific layers depend on THIS: adom/hydrogen-windows-bootstrap (WSL2), adom/hydrogen-mac-bootstrap, adom/hydrogen-ubuntu-bootstrap. The reference design other orgs copy to build their own bootstrap on adom/core.", "org": "adom", "platform": "any", "tags": [ "bootstrap",- "hydrogen-desktop",- "hd",+ "hydrogen", "workspace" ], "needs_sudo": false,
page.json+4−5@@ -3,14 +3,13 @@ "slug": "hydrogen-bootstrap", "type": "bootstrap", "title": "Adom Hydrogen (platform base)",- "brief": "Layer Hydrogen Desktop's workspace onto a standard Adom workstation.",- "version": "0.3.0",- "description": "Hydrogen Desktop's PLATFORM-GENERIC workspace layer on top of adom/core. Installs adom/core for the full Adom ecosystem, then adds everything common to running inside Hydrogen Desktop on ANY platform: the runtime-neutral hd-* skills and the generic HD editor configuration (Claude Code CLI + extension, VS Code settings, trusted domains). Platform-specific layers depend on THIS: adom/hd-windows-bootstrap (WSL2), adom/hd-mac-bootstrap, adom/hd-ubuntu-bootstrap. The reference design other orgs copy to build their own bootstrap on adom/core.",+ "brief": "Layer Hydrogen's workspace onto a standard Adom workstation.",+ "version": "0.3.1",+ "description": "Hydrogen's PLATFORM-GENERIC workspace layer on top of adom/core. Installs adom/core for the full Adom ecosystem, then adds everything common to running inside Hydrogen on ANY platform: the runtime-neutral hydrogen-* skills and the generic editor configuration (Claude Code CLI + extension, VS Code settings, trusted domains). Platform-specific layers depend on THIS: adom/hydrogen-windows-bootstrap (WSL2), adom/hydrogen-mac-bootstrap, adom/hydrogen-ubuntu-bootstrap. The reference design other orgs copy to build their own bootstrap on adom/core.", "org": "adom", "tags": [ "bootstrap",- "hydrogen-desktop",- "hd",+ "hydrogen", "workspace" ], "needs_sudo": false,
skills/hydrogen-adom-auth/SKILL.md+1−1@@ -11,7 +11,7 @@ description: > HD adom login, Your profile, Your repositories. --- -# Hydrogen Desktop -- Authentication Reference+# Hydrogen -- Authentication Reference ## Auth Flow Overview
skills/hydrogen-adom-desktop/SKILL.md+36−36@@ -1,7 +1,7 @@ --- name: hydrogen-adom-desktop description: >- What Hydrogen Desktop (HD) and Adom Desktop (AD) are, what each does, and how+ What Hydrogen (HD) and Adom Bridge (AD) are, what each does, and how they work together — so the AI in the workspace knows it has HANDS on the user's real operating system. HD is the workspace app the user looks at; AD is the bridge that reaches the user's actual machine to create files & folders,@@ -16,15 +16,15 @@ description: > on my machine, control the host, host screenshot, screenshot my screen, os screenshot, open a file on my computer, control my desktop, bridge to my pc, send file to my desktop, pull file from my desktop, hd and ad, two apps, how- do hd and ad work together, talk to hydrogen desktop, desktop bridge, relay,- embedded mode, AD hidden, hd_status, hd_api, shell_execute, adom-desktop ping,- adom-desktop status.+ do hd and ad work together, talk to hydrogen, desktop bridge, relay,+ embedded mode, AD hidden, hd_status, hd_api, shell_execute, adom-bridge-cli ping,+ adom-bridge-cli status. --- -# Hydrogen Desktop ↔ Adom Desktop — your reach onto the user's real machine+# Hydrogen ↔ Adom Bridge — your reach onto the user's real machine You (the AI) run inside the **HD workspace** (a local Linux workspace on the-user's machine). That's a sandbox. **Adom Desktop (AD) is how you reach OUT of it+user's machine). That's a sandbox. **Adom Bridge (AD) is how you reach OUT of it onto the user's actual operating system** — their real files, shell, screen, and desktop apps. Knowing AD exists is the difference between "I can only work in here" and "I can create that file on your Desktop, screenshot your screen, and@@ -32,13 +32,13 @@ open it in KiCad." > **Platform note:** HD's host layer (file/shell/screenshot/notification/window > control) is platform-specific. Before promising a host action on a given OS,-> verify the capability with `adom-desktop status` rather than assuming it.+> verify the capability with `adom-bridge-cli status` rather than assuming it. > For Windows/WSL2-specific host behavior, see the [[hydrogen-adom-desktop-windows]] > companion skill. ## Two apps, two jobs -| | **Hydrogen Desktop (HD)** | **Adom Desktop (AD)** |+| | **Hydrogen (HD)** | **Adom Bridge (AD)** | |---|---|---| | What it is | The user-facing workspace app (Tauri). VS Code pane + Wiki + the runtime that hosts your workspace. | A bridge app that talks to the user's real OS and local apps. | | What the user sees | The window they work in. | Usually nothing — HD hides it (embedded mode). |@@ -71,13 +71,13 @@ Here's the subtlety that matters when you reason about "who serves this verb?": `desktop_record_*`, `desktop_recorder_*`, `desktop_list_monitors`, `desktop_pull_glob`, `desktop_embedded_*`. -Both ends sit behind the same `adom-desktop` relay, so from the CLI you don't+Both ends sit behind the same `adom-bridge-cli` relay, so from the CLI you don't choose between them — the relay routes to whichever client is connected. But "will this verb work right now?" depends on which client is up. **Don't assume a verb exists — verify capability first:** ```bash-adom-desktop status # → .capabilities lists what the connected client(s) can do+adom-bridge-cli status # → .capabilities lists what the connected client(s) can do ``` If `.capabilities` is missing `record` (or `desktop_list_monitors` errors with@@ -88,7 +88,7 @@ the KiCad/Fusion/browser bridges all work off HD's built-in bridge regardless. ## What AD/HD let you do on the user's real machine -All via the `adom-desktop` CLI from inside the workspace. Rather than+All via the `adom-bridge-cli` CLI from inside the workspace. Rather than re-document every verb here, this is a **capability map → the focused skill**: | Capability | Verb(s) / surface | Where it's documented |@@ -104,8 +104,8 @@ re-document every verb here, this is a **capability map → the focused skill**: | **Drive KiCad / Fusion 360 / Pup** | `kicad_*`, `fusion_*`, `browser_*` | [hydrogen-bridges](../hydrogen-bridges/SKILL.md) | | **Embedded mechanics (tray/lifecycle)** | `desktop_embedded_*` | [hd-embedded-ad](../hd-embedded-ad/SKILL.md) — AD-served | -For the complete verb list run `adom-desktop list_commands` (or see the-`adom-desktop` skill).+For the complete verb list run `adom-bridge-cli list_commands` (or see the+`adom-bridge-cli` skill). ### Host shell-trust model @@ -115,13 +115,13 @@ blocked on per-command approval dialogs — convenient, but it means anything yo run there really runs. Revoke the standing auto-approval at any time: ```bash-adom-desktop shell_auto_approve '{"duration_secs":0}' # turn auto-approve off now+adom-bridge-cli shell_auto_approve '{"duration_secs":0}' # turn auto-approve off now ``` When you *don't* need a free-form shell, prefer the **no-escape structured runners** over hand-quoted `shell_execute` (AD ≥ 1.8.50):-`adom-desktop run_script '{"interpreter":"bash|cmd|powershell","scriptB64":"<b64>"}'`-and `adom-desktop wsl_exec '{"distro":"<workspace-distro>","user":"adom","scriptB64":"<b64>"}'`+`adom-bridge-cli run_script '{"interpreter":"bash|cmd|powershell","scriptB64":"<b64>"}'`+and `adom-bridge-cli wsl_exec '{"distro":"<workspace-distro>","user":"adom","scriptB64":"<b64>"}'` — base64 the script so no quoting survives to be mangled. (`wsl_exec` is a Windows/WSL2 path — see the [[hydrogen-adom-desktop-windows]] companion.) @@ -145,41 +145,41 @@ without manual `send_files`/`pull_file` round-trips. ## Talking to HD + AD from the CLI -You reach the host through the **`adom-desktop` CLI**, which relays your commands+You reach the host through the **`adom-bridge-cli` CLI**, which relays your commands over a WebSocket to the desktop client(s). **Host shell + files:** ```bash-adom-desktop shell_execute '{"command":"<cmd>","timeoutSeconds":60}'-adom-desktop pull_file '{"filePaths":["<host path>"],"saveTo":"/tmp"}'-adom-desktop send_files '{"filePaths":["/tmp/x"],"saveTo":"<host dir>"}'-adom-desktop desktop_list_windows+adom-bridge-cli shell_execute '{"command":"<cmd>","timeoutSeconds":60}'+adom-bridge-cli pull_file '{"filePaths":["<host path>"],"saveTo":"/tmp"}'+adom-bridge-cli send_files '{"filePaths":["/tmp/x"],"saveTo":"<host dir>"}'+adom-bridge-cli desktop_list_windows ``` -**Hydrogen Desktop control (the HD app itself):**+**Hydrogen control (the HD app itself):** ```bash-adom-desktop hd_status # is HD running + composed runtime state-adom-desktop hd_screenshot # window-bounded HD shot (resize <1500px before reading!)-adom-desktop hd_log # tail HD's log-adom-desktop hd_launch # start HD detached+adom-bridge-cli hd_status # is HD running + composed runtime state+adom-bridge-cli hd_screenshot # window-bounded HD shot (resize <1500px before reading!)+adom-bridge-cli hd_log # tail HD's log+adom-bridge-cli hd_launch # start HD detached # Direct HD control API (HTTP, no shell-escaping pain):-adom-desktop hd_api '{"method":"POST","path":"/setup/run-all","body":{}}'-adom-desktop hd_api '{"method":"GET","path":"/health"}'+adom-bridge-cli hd_api '{"method":"POST","path":"/setup/run-all","body":{}}'+adom-bridge-cli hd_api '{"method":"GET","path":"/health"}' ``` `hd_api` hits HD's **control API** on its discovered port (fallback **47084**). See the [[hydrogen-adom-desktop-windows]] companion for the host port-discovery file. **Embedded-mode introspection (AD-served):** ```bash-adom-desktop desktop_embedded_status # embedded=true/false, enteredVia=launch-flag|runtime-adopt+adom-bridge-cli desktop_embedded_status # embedded=true/false, enteredVia=launch-flag|runtime-adopt ``` ## How the connection works (and how you check it) ``` You (AI in the workspace)- └─ adom-desktop <verb> '<json>' ← CLI in the workspace- └─ relay (adom-desktop serve: WS :8765 + HTTP :8766, started in the workspace)+ └─ adom-bridge-cli <verb> '<json>' ← CLI in the workspace+ └─ relay (adom-bridge-cli serve: WS :8765 + HTTP :8766, started in the workspace) └─ WebSocket ──► HD's built-in bridge AND/OR the embedded AD on the user's machine └─ acts on the OS / KiCad / Fusion / Chrome ```@@ -191,11 +191,11 @@ You (AI in the workspace) for the WSL2 loopback-forwarding details). - **Always verify the bridge before acting on the host:** ```bash- adom-desktop ping # → {"status":"connected", ...} means a client is reachable- adom-desktop status # who's connected + .capabilities + which local apps are installed/running+ adom-bridge-cli ping # → {"status":"connected", ...} means a client is reachable+ adom-bridge-cli status # who's connected + .capabilities + which local apps are installed/running ``` If `ping` fails, no desktop client is connected — tell the user, and (if needed)- walk the `adom-desktop` setup steps. Don't claim you acted on their machine+ walk the `adom-bridge-cli` setup steps. Don't claim you acted on their machine without a successful round-trip. Don't try to "fix" a dead host client from in here — surface it. @@ -219,7 +219,7 @@ When the user asks for something that lives on their real computer — "save thi to my Desktop", "what's on my screen", "open this in KiCad", "run this command on my machine" — that's an **AD** job, and you can do it. When it's about the workspace itself (editor, files under `/home/adom/project`, the runtime), that's-**HD**. Lead with what you can do, verify with `adom-desktop ping`, then act.+**HD**. Lead with what you can do, verify with `adom-bridge-cli ping`, then act. ## Related skills - [[hydrogen-adom-desktop-windows]] — Windows/WSL2 host specifics (paths, winget installs, loopback forwarding, taskkill)@@ -230,5 +230,5 @@ workspace itself (editor, files under `/home/adom/project`, the runtime), that's - [hd-recording](../hd-recording/SKILL.md) — screen vs tab recording (AD-served) - [hydrogen-notifications](../hydrogen-notifications/SKILL.md) — desktop toasts; [hydrogen-captions](../hydrogen-captions/SKILL.md) — on-screen caption overlay - [hydrogen-open-url](../hydrogen-open-url/SKILL.md) — the ways to open a URL (Pup, native browser, picker, …)-- `pup` — driving Pup browser windows; `adom-desktop` — the full CLI verb reference+- `pup` — driving Pup browser windows; `adom-bridge-cli` — the full CLI verb reference - [hd-runtime-mode](../hd-runtime-mode/SKILL.md) — the HD↔AD relationship is identical across runtimes
skills/hydrogen-adom-menu/SKILL.md+7−8@@ -1,14 +1,14 @@ --- name: hydrogen-adom-menu description: >- The Adom menu — the logo dropdown in the UPPER-LEFT corner of Hydrogen Desktop+ The Adom menu — the logo dropdown in the UPPER-LEFT corner of Hydrogen (click the teal Adom logo). It is the hub for app-level actions: Go to- Dashboard, Settings, Ports, API Explorer, and a Desktop section (Adom Desktop,+ Dashboard, Settings, Ports, API Explorer, and a Desktop section (Adom Bridge, Zoom, Fullscreen, Console, Developer Tools, Dev Toolbar), a Container section (Start/Restart/Stop), and an Admin section (Setup Steps, Virgin Reset, Browser Picker Manager). Also covers the window TITLE BAR version readout and the About dialog (version/sha/build/signed +- Adom Desktop version + wiki/repo links). Use when the user asks "what's in the+ Adom Bridge version + wiki/repo links). Use when the user asks "what's in the Adom menu", "where's settings/devtools/about", "what version am I running", or about any upper-left menu item. NOTE: this is the upper-LEFT logo menu — the upper-RIGHT avatar dropdown is hydrogen-profile-menu. Trigger words: adom menu, logo@@ -36,7 +36,7 @@ logo = go straight to the Dashboard.) Source: `EditorNav.svelte` → `.logo-butt | **Ports…** | Configure local host port assignments for HD services (`SettingsPortsDialog`) | | **API Explorer…** | Browse + test every HD control-API endpoint (`ApiExplorerDialog`); see **hydrogen-api** | | *— Desktop —* | (desktop-only section, shown when running in HD/Tauri; in order) |-| **Adom Desktop** | Bring the embedded Adom Desktop window to the foreground (taskbar) — FIRST item in the section |+| **Adom Bridge** | Bring the embedded Adom Bridge window to the foreground (taskbar) — FIRST item in the section | | **Zoom** | −/+ zoom the whole HD UI (persisted) | | **Fullscreen** | Toggle fullscreen | | **Console** | Show/hide the native HD debug console window |@@ -67,13 +67,12 @@ inspect/inject into any panel. ## Version readout — title bar + About dialog **Title bar** (always visible) shows, in order:-`Hydrogen Desktop v<version> · <dev|release> · <sha>-dirty · <build time> · <signed|unsigned> · AD <ad-version>`+`Hydrogen v<version> · <dev|release> · <sha>-dirty · <build time> · <signed|unsigned> · AD <ad-version>` — a fast way to confirm which build is running and whether it's signed. **About dialog** (deep version info) — open it from the **tray menu → "About-Hydrogen Desktop"** (emits the `show-about` event; the dialog is mounted-app-wide). It shows, for **both** Hydrogen Desktop and the embedded **Adom-Desktop**:+Hydrogen"** (emits the `show-about` event; the dialog is mounted+app-wide). It shows, for **both** Hydrogen and the embedded **Adom Bridge**: - Version, channel (dev/release), signed yes/no, commit SHA (+dirty), build time, install path, and reachability/endpoint (for AD) - Links to each app's GitHub repo and **Wiki v1 + Wiki v2** pages (they're git
skills/hydrogen-api/SKILL.md+4−4@@ -1,7 +1,7 @@ --- name: hydrogen-api description: >- Complete reference for Hydrogen Desktop control API endpoints. The control+ Complete reference for Hydrogen control API endpoints. The control API runs on a dynamic port (find it via port discovery). Use these endpoints to drive HD programmatically: manage the workspace runtime, control Claude Code, manipulate VS Code, manage workspace tabs, run setup steps, trigger@@ -35,7 +35,7 @@ The control API port is dynamic (default 47084, auto-resolves conflicts). ```bash # From HD log-adom-desktop hd_log '{"tail":100}' | grep "control="+adom-bridge-cli hd_log '{"tail":100}' | grep "control=" # From inside the workspace — USE THIS. HD writes its live control URL to a discovery # file every launch, so you never hunt for the dynamic port:@@ -63,13 +63,13 @@ which is unchanged for web-hydrogen parity. ## AD-health diagnostics (`/ad/*`) -These verify the **adom-desktop / relay / embedded-AD** half of HD is alive (the+These verify the **adom-bridge-cli / relay / embedded-AD** half of HD is alive (the bridge that connects this cloud container to HD). All GET, all return `{ok, ...}`. | Method | Path | Description | |---|---|---| | GET | `/ad/health` | Overall embedded-AD health roll-up |-| GET | `/ad/process` | Is the adom-desktop process running |+| GET | `/ad/process` | Is the adom-bridge-cli process running | | GET | `/ad/embedded` | Embedded-AD module status | | GET | `/ad/workspace-direct` | ⭐ The **converged** check — direct path to the workspace relay (use this one) | | GET | `/ad/relay` | Relay (WS/HTTP) reachability |
skills/hydrogen-bridges/SKILL.md+57−57@@ -3,7 +3,7 @@ name: hydrogen-bridges description: > Complete reference for the HD bridge ecosystem: the built-in KiCad, Fusion 360, and Puppeteer bridges, plus the extensible wiki bridge catalog (e.g. Blender)- and the full set of Adom Desktop capabilities. How they connect through adom-desktop, the Bridge Manager+ and the full set of Adom Bridge capabilities. How they connect through adom-bridge-cli, the Bridge Manager dialog, bridge status polling, and all bridge CLI commands. Use when the AI needs to take screenshots, control KiCad/Fusion/browser, transfer files, interact with the user's desktop, or check bridge status. Trigger words --@@ -12,7 +12,7 @@ description: > bridge manager, bridge status, bridge install. --- -# Hydrogen Desktop -- Bridge Ecosystem+# Hydrogen -- Bridge Ecosystem HD is the bridge between your Docker container and the user's Windows desktop. All commands go through the relay at ws://localhost:8765/.@@ -31,17 +31,17 @@ ecosystem, not a fixed list — new bridges ship via the wiki catalog (see | `fusion-bridge` | Fusion 360 Bridge | 8773 | Fusion 360 | Control Fusion 360 CAD/CAM and EAGLE PCB | | `puppeteer-bridge` | Puppeteer Bridge | 8851 | Chrome for Testing | Chrome automation, screenshots, and recording | -**Bridge ports have conventional defaults** (KiCad **8771**, Fusion **8773**, Pup **8851**), but adom-desktop registers the **live** port at bridge launch and may pick a different one if a default is taken. To find the actual live port, run `adom-desktop status` and look at `desktop.apps.<bridge>.bridgePort` (or `adom-desktop bridge_list`). In practice you don't need the port directly — use the `adom-desktop <verb>` CLI which routes to the right bridge automatically.+**Bridge ports have conventional defaults** (KiCad **8771**, Fusion **8773**, Pup **8851**), but adom-bridge-cli registers the **live** port at bridge launch and may pick a different one if a default is taken. To find the actual live port, run `adom-bridge-cli status` and look at `desktop.apps.<bridge>.bridgePort` (or `adom-bridge-cli bridge_list`). In practice you don't need the port directly — use the `adom-bridge-cli <verb>` CLI which routes to the right bridge automatically. Bridges are launched on demand by HD. They are NOT always running. The Bridge Manager polls status every 15 seconds via Tauri `invoke('get_bridge_status')`. -### What Adom Desktop can do (live capability list)+### What Adom Bridge can do (live capability list) Bridges are only part of AD. Query the **authoritative, machine-specific** list: ```bash-adom-desktop status # → .capabilities and .desktop.apps+adom-bridge-cli status # → .capabilities and .desktop.apps ``` On a typical machine `.capabilities` =@@ -55,7 +55,7 @@ Mapping to where each is documented: | `files` | send_files / pull_file | **hd-file-transfer**, **hydrogen-adom-desktop** | | `notify` | desktop toast notifications | this skill | | `shell` | run a command on the user's PC (approval-gated) | **hydrogen-adom-desktop** |-| `usb` | USB passthrough to the workspace (e.g. workcell hardware over USBIP) | not yet covered — query `adom-desktop status`; future skill |+| `usb` | USB passthrough to the workspace (e.g. workcell hardware over USBIP) | not yet covered — query `adom-bridge-cli status`; future skill | > `.desktop.apps` also reports, per app: `bridgeRunning`, `installed`, `running`, > `version` — use it to check whether the target app (KiCad/Fusion/Chrome) is@@ -77,7 +77,7 @@ interface BridgeInfo { display_name: string // e.g. "KiCad Bridge" version: string // e.g. "1.0.0" description: string- port: number // conventional default; live port via `adom-desktop status`+ port: number // conventional default; live port via `adom-bridge-cli status` status: 'running' | 'stopped' | 'not_installed' app_detected: boolean // true if target app (KiCad, Fusion, Chrome) is found app_name: string // e.g. "KiCad"@@ -106,7 +106,7 @@ each bridge's status. Auto-refreshes every 15 seconds. > the dialog shows an install link — but the AI doesn't have to stop there. For > KiCad and Node.js you can trigger an **unattended winget install** instead of > asking the user to download:-> `adom-desktop desktop_install_kicad '{}'` / `adom-desktop desktop_install_node '{}'`.+> `adom-bridge-cli desktop_install_kicad '{}'` / `adom-bridge-cli desktop_install_node '{}'`. > (Fusion 360 cannot be installed programmatically — surface the link for that.) ### CSS selectors@@ -158,7 +158,7 @@ setTimeout(function() { ## Prerequisites -Check connection: `adom-desktop ping` -- returns "pong" if HD is connected.+Check connection: `adom-bridge-cli ping` -- returns "pong" if HD is connected. If not connected, the user needs to launch HD on their Windows machine. ---@@ -167,16 +167,16 @@ If not connected, the user needs to launch HD on their Windows machine. ```bash # Full screen capture-adom-desktop desktop_screenshot_screen+adom-bridge-cli desktop_screenshot_screen # Resized for Claude vision (default to this)-adom-desktop desktop_screenshot_screen '{"maxWidth": 1500}'+adom-bridge-cli desktop_screenshot_screen '{"maxWidth": 1500}' # Specific window by HWND-adom-desktop desktop_screenshot_window '{"hwnd": 12345}'+adom-bridge-cli desktop_screenshot_window '{"hwnd": 12345}' # List all capturable windows-adom-desktop desktop_list_windows+adom-bridge-cli desktop_list_windows ``` **AI guidance:**@@ -189,46 +189,46 @@ adom-desktop desktop_list_windows ## Browser Automation (Puppeteer Bridge) -Port: default **8851** (adom-desktop registers the live port; see `adom-desktop status`). Auto-downloads Chrome for Testing if not present.+Port: default **8851** (adom-bridge-cli registers the live port; see `adom-bridge-cli status`). Auto-downloads Chrome for Testing if not present. ```bash # Open browser window-adom-desktop browser_open_window '{"url": "https://example.com"}'+adom-bridge-cli browser_open_window '{"url": "https://example.com"}' # Screenshot current tab-adom-desktop browser_screenshot '{"sessionId": "default"}'+adom-bridge-cli browser_screenshot '{"sessionId": "default"}' # Evaluate JavaScript-adom-desktop browser_eval '{"js": "document.title", "sessionId": "default"}'+adom-bridge-cli browser_eval '{"js": "document.title", "sessionId": "default"}' # Navigate-adom-desktop browser_navigate '{"url": "https://...", "sessionId": "default"}'+adom-bridge-cli browser_navigate '{"url": "https://...", "sessionId": "default"}' # List open windows/tabs-adom-desktop browser_list_windows+adom-bridge-cli browser_list_windows # Record tab (CDP screencast, zero dialogs)-adom-desktop browser_record_start '{"sessionId": "default"}'-adom-desktop browser_record_stop '{"sessionId": "default"}'+adom-bridge-cli browser_record_start '{"sessionId": "default"}'+adom-bridge-cli browser_record_stop '{"sessionId": "default"}' ``` --- ## KiCad Bridge -Port: default **8771** (adom-desktop registers the live port; see `adom-desktop status`). Requires KiCad to be installed on the user's Windows machine.+Port: default **8771** (adom-bridge-cli registers the live port; see `adom-bridge-cli status`). Requires KiCad to be installed on the user's Windows machine. ```bash-adom-desktop kicad_open_board '{"path": "C:\\path\\to\\board.kicad_pcb"}'-adom-desktop kicad_open_schematic '{"path": "C:\\path\\to\\schematic.kicad_sch"}'-adom-desktop kicad_open_3d_viewer-adom-desktop kicad_run_drc '{"path": "..."}'-adom-desktop kicad_screenshot_all-adom-desktop kicad_window_info-adom-desktop kicad_send_key '{"key": "ctrl+s"}'-adom-desktop kicad_list_versions-adom-desktop kicad_install_symbol '{"path": "/tmp/symbol.kicad_sym", "library": "MyLib"}'-adom-desktop kicad_install_library '{"path": "/tmp/footprints", "name": "MyFootprints"}'+adom-bridge-cli kicad_open_board '{"path": "C:\\path\\to\\board.kicad_pcb"}'+adom-bridge-cli kicad_open_schematic '{"path": "C:\\path\\to\\schematic.kicad_sch"}'+adom-bridge-cli kicad_open_3d_viewer+adom-bridge-cli kicad_run_drc '{"path": "..."}'+adom-bridge-cli kicad_screenshot_all+adom-bridge-cli kicad_window_info+adom-bridge-cli kicad_send_key '{"key": "ctrl+s"}'+adom-bridge-cli kicad_list_versions+adom-bridge-cli kicad_install_symbol '{"path": "/tmp/symbol.kicad_sym", "library": "MyLib"}'+adom-bridge-cli kicad_install_library '{"path": "/tmp/footprints", "name": "MyFootprints"}' ``` **Always run `kicad_window_info` BEFORE any KiCad operation** to check for modal dialogs —@@ -240,12 +240,12 @@ you detect a KiCad error/blocking dialog** (a save-permission error, a file-form DRC blocker). Each entry is `{hwnd, ownerHwnd, title}` (e.g. `title:"Error"`): ```bash-adom-desktop kicad_window_info '{}'+adom-bridge-cli kicad_window_info '{}' # → { editors:[...], hasModalDialogs:true, # modalDialogs:[{ "hwnd":200934, "ownerHwnd":6163368, "title":"Error" }], projectManager:{...} } ``` - ⚠️ `modalDialogs` gives the **title + hwnd, NOT the body text**. To read *what the error says*,- **screenshot the dialog by its hwnd**: `adom-desktop desktop_screenshot_window '{"hwnd":200934}'`+ **screenshot the dialog by its hwnd**: `adom-bridge-cli desktop_screenshot_window '{"hwnd":200934}'` → read the saved PNG. (Verified live 2026-06-15: a `ctrl+s` on a read-only board surfaced `hasModalDialogs:true` + a `title:"Error"` entry; screenshotting its hwnd read *"Insufficient permissions to save file …"*.)@@ -259,14 +259,14 @@ adom-desktop kicad_window_info '{}' ## Fusion 360 Bridge -Port: default **8773** (adom-desktop registers the live port; see `adom-desktop status`). Requires Fusion 360 to be installed on the user's Windows machine.+Port: default **8773** (adom-bridge-cli registers the live port; see `adom-bridge-cli status`). Requires Fusion 360 to be installed on the user's Windows machine. ```bash-adom-desktop fusion_start-adom-desktop fusion_import_step '{"path": "C:\\path\\to\\model.step"}'-adom-desktop fusion_export_step '{"path": "C:\\path\\to\\output.step"}'-adom-desktop fusion_board_info-adom-desktop fusion_electron_run '{"command": "..."}'+adom-bridge-cli fusion_start+adom-bridge-cli fusion_import_step '{"path": "C:\\path\\to\\model.step"}'+adom-bridge-cli fusion_export_step '{"path": "C:\\path\\to\\output.step"}'+adom-bridge-cli fusion_board_info+adom-bridge-cli fusion_electron_run '{"command": "..."}' ``` ---@@ -274,23 +274,23 @@ adom-desktop fusion_electron_run '{"command": "..."}' ## Extensible bridge catalog (bridges are NOT a fixed set) Bridges are a growing ecosystem. The three above (KiCad / Fusion 360 / Puppeteer)-are **built into Adom Desktop**. Additional bridges are published to the **wiki+are **built into Adom Bridge**. Additional bridges are published to the **wiki bridge catalog** and installed on demand — for example the **Blender bridge**-(`adom-blender-bridge`), which is NOT built in (it won't appear in `adom-desktop+(`adom-blender-bridge`), which is NOT built in (it won't appear in `adom-bridge-cli status` until installed). To use a catalog bridge: - **Discover:** Bridge Manager → "Browse Bridge Catalog" → wiki `/apps?tag=hd-bridge`. - **Reserved ports:** the `8900-8999` range is set aside for 3rd-party bridges.-- **Enumerate what's actually live:** `adom-desktop status` → `desktop.apps.*` lists+- **Enumerate what's actually live:** `adom-bridge-cli status` → `desktop.apps.*` lists every bridge AD currently knows about, with `bridgePort`, `status`, and whether the target app was detected. **Treat that as the source of truth** for "what bridges exist right now" — this skill's table lists the core ones, but new catalog bridges will appear in `status` without being in this table.-- **Invoke any bridge** through the `adom-desktop <verb>` CLI; it routes to the+- **Invoke any bridge** through the `adom-bridge-cli <verb>` CLI; it routes to the right bridge automatically (you rarely need the port directly). > Maintainer note: keep this skill in sync by periodically running-> `adom-desktop status` against a fully-bridged machine and reconciling the table.+> `adom-bridge-cli status` against a fully-bridged machine and reconciling the table. --- @@ -298,10 +298,10 @@ status` until installed). To use a catalog bridge: ```bash # Send file from Docker to Windows desktop-adom-desktop send_files '{"files": [{"path": "/home/adom/project/output.pdf"}]}'+adom-bridge-cli send_files '{"files": [{"path": "/home/adom/project/output.pdf"}]}' # Pull file from Windows to Docker-adom-desktop pull_file '{"remotePath": "C:\\Users\\john\\Downloads\\data.csv", "localPath": "/tmp/data.csv"}'+adom-bridge-cli pull_file '{"remotePath": "C:\\Users\\john\\Downloads\\data.csv", "localPath": "/tmp/data.csv"}' ``` ---@@ -310,16 +310,16 @@ adom-desktop pull_file '{"remotePath": "C:\\Users\\john\\Downloads\\data.csv", " ```bash # Toast notification-adom-desktop notify_user '{"message": "Build complete!", "duration_ms": 5000}'+adom-bridge-cli notify_user '{"message": "Build complete!", "duration_ms": 5000}' # Open URL in user's browser-adom-desktop desktop_open_url '{"url": "https://..."}'+adom-bridge-cli desktop_open_url '{"url": "https://..."}' # Open folder in Explorer-adom-desktop desktop_open_folder '{"path": "C:\\Users\\john\\project"}'+adom-bridge-cli desktop_open_folder '{"path": "C:\\Users\\john\\project"}' # Execute shell command (requires user approval)-adom-desktop shell_execute '{"command": "dir C:\\Github"}'+adom-bridge-cli shell_execute '{"command": "dir C:\\Github"}' ``` ---@@ -329,7 +329,7 @@ adom-desktop shell_execute '{"command": "dir C:\\Github"}' > **Served by the embedded AD process, NOT HD's built-in bridge.** The > `desktop_record_*` / `desktop_recorder_*` verbs only exist when the standalone > AD (spawned `--embedded`) is connected. Verify before using:-> `adom-desktop status` → `.capabilities` must include `record`. If it's absent,+> `adom-bridge-cli status` → `.capabilities` must include `record`. If it's absent, > only HD's built-in bridge is up and these verbs return "unknown desktop > command". See **hd-recording** for full details. @@ -341,12 +341,12 @@ adom-desktop shell_execute '{"command": "dir C:\\Github"}' ```bash # Record entire desktop (AD-served; needs the confirm guard, zero dialogs)-adom-desktop desktop_record_start '{"reason": "Demo recording", "confirmDesktopNotTabRecording": true}'-adom-desktop desktop_record_stop+adom-bridge-cli desktop_record_start '{"reason": "Demo recording", "confirmDesktopNotTabRecording": true}'+adom-bridge-cli desktop_record_stop # Record a single browser tab (CDP screencast, zero dialogs) — prefer this for one tab-adom-desktop browser_record_start '{"sessionId": "default"}'-adom-desktop browser_record_stop '{"sessionId": "default"}'+adom-bridge-cli browser_record_start '{"sessionId": "default"}'+adom-bridge-cli browser_record_stop '{"sessionId": "default"}' ``` ---@@ -355,7 +355,7 @@ adom-desktop browser_record_stop '{"sessionId": "default"}' ```bash # 1. Take screenshot-adom-desktop desktop_screenshot_screen '{"maxWidth": 1500}'+adom-bridge-cli desktop_screenshot_screen '{"maxWidth": 1500}' # 2. Read the screenshot (it's saved to /screenshots/) # 3. Analyze with Claude vision # 4. Make changes
skills/hydrogen-captions/SKILL.md+3−3@@ -1,7 +1,7 @@ --- name: hydrogen-captions description: >- Paint labeled caption text on the Hydrogen Desktop workspace for demos/walkthroughs —+ Paint labeled caption text on the Hydrogen workspace for demos/walkthroughs — captions are CAPTURED BY RECORDINGS so they show up in the finished video. Drive the WORKSPACE caption with `adom-cli hydrogen caption` — THE default, identical on web-Hydrogen AND HD (text positional; `-d` duration in SECONDS not ms; 30s auto-expire@@ -18,9 +18,9 @@ description: > persist caption. --- -# Hydrogen Desktop — On-Screen Captions+# Hydrogen — On-Screen Captions -You can **paint labeled caption text on the Hydrogen Desktop workspace** for demos and+You can **paint labeled caption text on the Hydrogen workspace** for demos and walkthroughs — and because captions are real pixels, **they're captured by recordings**, so they end up in the finished video ("Step 3: run DRC →").
skills/hydrogen-capture-share/SKILL.md+1−1@@ -17,7 +17,7 @@ description: > capture, capture scope, panel screenshot, capture frame, share with the AI. --- -# Hydrogen Desktop — Screen Capture & Sharing (the AI-consent surface)+# Hydrogen — Screen Capture & Sharing (the AI-consent surface) This is the surface **you (the AI) trigger to see HD's own screen.** To screenshot the *editor* (panels, the workspace, or the whole monitor) into the container, a
skills/hydrogen-container/SKILL.md+25−25@@ -1,11 +1,11 @@ --- name: hydrogen-container-description: Context for Claude Code running inside a Hydrogen Desktop workspace. Documents the exact OS (Ubuntu 24.04, code-server, the local workspace), explains how setup differs from Adom cloud containers (HD setup-steps NOT bootstrap.sh), what bridges are available, and how to use the relay. Trigger on startup, adom-cli errors, bridge commands, screenshot requests, container-platform questions, code-server / VS Code extension issues, or when the AI needs concrete facts about its environment instead of guessing.+description: Context for Claude Code running inside a Hydrogen workspace. Documents the exact OS (Ubuntu 24.04, code-server, the local workspace), explains how setup differs from Adom cloud containers (HD setup-steps NOT bootstrap.sh), what bridges are available, and how to use the relay. Trigger on startup, adom-cli errors, bridge commands, screenshot requests, container-platform questions, code-server / VS Code extension issues, or when the AI needs concrete facts about its environment instead of guessing. --- -# Hydrogen Desktop Workspace+# Hydrogen Workspace -You are running inside the **local workspace** managed by Hydrogen Desktop (HD). HD is the flagship Adom desktop app — it manages your workspace, bridges to desktop apps, and provides VS Code + Claude Code. HD runs on Windows, macOS, and Ubuntu; the platform-specific mechanics of how the workspace is hosted are abstracted away from inside the workspace — the facts below hold regardless of host OS.+You are running inside the **local workspace** managed by Hydrogen (HD). HD is the flagship Adom desktop app — it manages your workspace, bridges to desktop apps, and provides VS Code + Claude Code. HD runs on Windows, macOS, and Ubuntu; the platform-specific mechanics of how the workspace is hosted are abstracted away from inside the workspace — the facts below hold regardless of host OS. > Platform layers add a `*-windows` companion to this skill (`[[hydrogen-container-windows]]`) with the host-specific spine — the WSL2 `Adom-Workspace` distro, `wsl --import`, code-server port auto-forward, the runtime source, and the Cloud-vs-local comparison table. @@ -51,10 +51,10 @@ If this returns user data, all adom-cli commands work (containers, repos, orgs, ## Relay server is running -The adom-desktop relay runs on ports 8765 (WebSocket) / 8766 (HTTP) inside this workspace. The `start-relay` setup step launches it.+The adom-bridge-cli relay runs on ports 8765 (WebSocket) / 8766 (HTTP) inside this workspace. The `start-relay` setup step launches it. Check health: `curl -sf http://127.0.0.1:8766/health`-Check desktop connection: `adom-desktop ping`+Check desktop connection: `adom-bridge-cli ping` The host control API is reachable from inside the workspace at `127.0.0.1`. The port is dynamic per launch, so read the live URL from `~/.adom/hd-control-url` (`http://127.0.0.1:<dynamic>`): `BASE="$(cat ~/.adom/hd-control-url)"; curl "$BASE/health"`. @@ -62,48 +62,48 @@ The host control API is reachable from inside the workspace at `127.0.0.1`. The ### Screenshots (zero dialogs, instant) ```bash-adom-desktop desktop_screenshot_screen # full screen capture-adom-desktop desktop_screenshot_screen '{"maxWidth":1500}' # resized for Claude vision-adom-desktop desktop_screenshot_window '{"hwnd": N}' # capture specific window-adom-desktop desktop_list_windows # list all windows with handles+adom-bridge-cli desktop_screenshot_screen # full screen capture+adom-bridge-cli desktop_screenshot_screen '{"maxWidth":1500}' # resized for Claude vision+adom-bridge-cli desktop_screenshot_window '{"hwnd": N}' # capture specific window+adom-bridge-cli desktop_list_windows # list all windows with handles ``` Default to `maxWidth: 1500, format: "png"` for UI screenshots. Use `"jpeg"` for natural photos, `"webp"` for smaller files. ### Browser automation (Puppeteer) ```bash-adom-desktop browser_open_window '{"url": "https://..."}'-adom-desktop browser_screenshot '{"sessionId": "default"}'-adom-desktop browser_eval '{"js": "document.title"}'-adom-desktop browser_navigate '{"url": "..."}'+adom-bridge-cli browser_open_window '{"url": "https://..."}'+adom-bridge-cli browser_screenshot '{"sessionId": "default"}'+adom-bridge-cli browser_eval '{"js": "document.title"}'+adom-bridge-cli browser_navigate '{"url": "..."}' ``` ### KiCad bridge ```bash-adom-desktop kicad_open_board '{"path": "/path/to/board.kicad_pcb"}'-adom-desktop kicad_screenshot_all-adom-desktop kicad_run_drc '{"path": "..."}'-adom-desktop kicad_window_info+adom-bridge-cli kicad_open_board '{"path": "/path/to/board.kicad_pcb"}'+adom-bridge-cli kicad_screenshot_all+adom-bridge-cli kicad_run_drc '{"path": "..."}'+adom-bridge-cli kicad_window_info ``` (Paths to host files use the host's native path convention.) ### Fusion 360 bridge ```bash-adom-desktop fusion_start-adom-desktop fusion_import_step '{"path": "..."}'-adom-desktop fusion_export_step '{"path": "..."}'+adom-bridge-cli fusion_start+adom-bridge-cli fusion_import_step '{"path": "..."}'+adom-bridge-cli fusion_export_step '{"path": "..."}' ``` ### File transfer ```bash-adom-desktop send_files '{"files": [{"path": "/home/adom/file.txt"}]}'-adom-desktop pull_file '{"remotePath": "<host path>", "localPath": "/tmp/file.txt"}'+adom-bridge-cli send_files '{"files": [{"path": "/home/adom/file.txt"}]}'+adom-bridge-cli pull_file '{"remotePath": "<host path>", "localPath": "/tmp/file.txt"}' ``` ### Desktop interaction ```bash-adom-desktop notify_user '{"message": "Build complete", "duration_ms": 3000}'-adom-desktop desktop_open_url '{"url": "https://..."}'-adom-desktop desktop_open_folder '{"path": "<host folder path>"}'+adom-bridge-cli notify_user '{"message": "Build complete", "duration_ms": 3000}'+adom-bridge-cli desktop_open_url '{"url": "https://..."}'+adom-bridge-cli desktop_open_folder '{"path": "<host folder path>"}' ``` ## What's different from Adom cloud containers
skills/hydrogen-desktop-sse/SKILL.md+4−4@@ -3,7 +3,7 @@ name: hydrogen-desktop-sse description: How HD's local workspace API + SSE works (a.k.a. the workspace API) — replaces Carbon for workspace commands so the workspace's adom-cli controls HD, not cloud Hydrogen. Covers the full pipeline, routing, env vars, field format differences, port discovery, and hard-won lessons. Trigger words — HD SSE, workspace API, local API, adom-cli workspace, add-tab, move-tab, webview tab, EventSource, workspace_updated, ADOM_CARBON_URL, ADOM_HYDROGEN_URL, discovery port. --- -# Hydrogen Desktop — Local Workspace API + SSE+# Hydrogen — Local Workspace API + SSE > Platform note: HD runs the same local workspace API on every platform (Windows/WSL2, > macOS, Linux). For the WSL2-specific networking details (mirrored loopback,@@ -138,7 +138,7 @@ adom-cli hydrogen workspace move-tab \ --to-panel-id desktop-pane-left # 5. Screenshot to verify-adom-desktop hd_screenshot+adom-bridge-cli hd_screenshot ``` ## What Broke and Why@@ -197,7 +197,7 @@ Returns: | Client | What it discovers | How | |---|---|---|-| adom-desktop relay | Control API port (was hardcoded 9001) | `curl :47080/discover` → use `control` field |+| adom-bridge-cli relay | Control API port (was hardcoded 9001) | `curl :47080/discover` → use `control` field | | adom-cli in the workspace | Proxy + Hydrogen URL | Already set via `ADOM_CARBON_URL` env var at workspace creation | | External tools / diagnostics | Any port | Hit discovery, get the full map | | Cloud Docker (this container) | All HD ports | `curl http://<desktop-ip>:47080/discover` via relay |@@ -242,4 +242,4 @@ On first launch, defaults are written without scanning. Workspace-side ports (80 | `src-tauri/crates/hd-app/src/lib.rs` | Discovery server on :47080, port resolution at startup | | `src/lib/stores/portStore.ts` | Frontend Svelte store, `initPorts()`, `controlUrl()`, `codeServerUrl()` | | `src/lib/components/editor/workspaces/PanelWorkspaceComponent.svelte` | Frontend SSE setup, autosave, workspace re-fetch |-| `scripts/hd-bootstrap.sh` | Sets adom-cli config, injects API key, uses `HD_CONTROL_PORT` env var |+| `scripts/hydrogen-bootstrap.sh` | Sets adom-cli config, injects API key, uses `HD_CONTROL_PORT` env var |
skills/hydrogen-eda-discovery/SKILL.md+9−9@@ -22,17 +22,17 @@ the user's electronics-design stack and show them what the AI-first Adom workflo **exploratory and opt-in** — detect first, then offer; never auto-install or auto-build. Do the detection in the background, then come back with a short, friendly summary + one clear offer. -## 1. Detect (via `adom-desktop` — see `hydrogen-adom-desktop`, `hydrogen-bridges`, `pup`)+## 1. Detect (via `adom-bridge-cli` — see `hydrogen-adom-desktop`, `hydrogen-bridges`, `pup`) ```bash-adom-desktop status # relay up? caps include kicad / fusion360?-adom-desktop kicad_list_versions '{}' # KiCad installed (+ which versions)-adom-desktop fusion_status '{}' # Fusion 360 installed? ("installed but not running" = yes)+adom-bridge-cli status # relay up? caps include kicad / fusion360?+adom-bridge-cli kicad_list_versions '{}' # KiCad installed (+ which versions)+adom-bridge-cli fusion_status '{}' # Fusion 360 installed? ("installed but not running" = yes) ``` The KiCad/Fusion bridges work the same on every platform. For tools with **no bridge** (Altium, OrCAD, Cadence/Allegro, EAGLE, DipTrace, Eplan, ...), there's no bridge verb — detect them by-**install path / running process** using `adom-desktop run_script`. The exact probe is+**install path / running process** using `adom-bridge-cli run_script`. The exact probe is platform-specific: - **Windows:** scan `C:\Program Files` / `C:\Program Files (x86)` and `Get-Process` via a@@ -55,7 +55,7 @@ platform-specific: ``` (Also worth a one-line memory note if you keep memories.) 2. **Show, don't tell** — offer to open an example so they *see* it work:- *"Want me to open a sample board in KiCad and pop the 3D viewer so you can see what I can drive?"* → use the `pic_programmer` demo flow (`hydrogen-self-screenshot`/`adom-desktop-kicad`): open `.kicad_sch` + `.kicad_pcb`, symbol/footprint editors, then the **board** 3D viewer (close the footprint+symbol editors first — `kicad_open_3d_viewer` attaches to the active editor otherwise).+ *"Want me to open a sample board in KiCad and pop the 3D viewer so you can see what I can drive?"* → use the `pic_programmer` demo flow (`hydrogen-self-screenshot`/`adom-bridge-cli-kicad`): open `.kicad_sch` + `.kicad_pcb`, symbol/footprint editors, then the **board** 3D viewer (close the footprint+symbol editors first — `kicad_open_3d_viewer` attaches to the active editor otherwise). 3. **Pitch the loop** that AI makes effortless — *"From here I can export gerbers and help you order the board — JLCPCB, PCBWay, or OSHPark."* If they're keen, that's the on-ramp to (4). 4. **The real unlock — build the glue, publish it.** Most fab vendors have no clean API, so the@@ -73,8 +73,8 @@ We don't have a bridge for these — **but that's an opportunity, not a dead end > probably ~30 minutes of vibe-coding. Then we publish it to the Adom wiki so every Altium > user gets it. We could all use it. Want to?"* -- Reference bridges: `adom-inc/adom-desktop/plugins/kicad/` and `…/plugins/fusion360/` (a Python- bridge that the desktop app dispatches to; see `adom-desktop-kicad`/`-fusion` for the verb+- Reference bridges: `adom-inc/adom-bridge-cli/plugins/kicad/` and `…/plugins/fusion360/` (a Python+ bridge that the desktop app dispatches to; see `adom-bridge-cli-kicad`/`-fusion` for the verb shape). A new bridge = the same pattern (launch app, open files, screenshot, send keys, an optional in-process add-in for the richer API). - Publish flow: the Adom wiki hosts shared apps (`apps/<name>`) — see the wiki publish skills.@@ -102,7 +102,7 @@ they can **contribute the missing piece** in half an hour. thing worth building.* ## Related skills-- [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) / [hydrogen-bridges](../hydrogen-bridges/SKILL.md) — the `adom-desktop` relay + KiCad/Fusion bridge verbs (in-distro names; the `adom-desktop-*` skills are the cloud-side equivalents)+- [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) / [hydrogen-bridges](../hydrogen-bridges/SKILL.md) — the `adom-bridge-cli` relay + KiCad/Fusion bridge verbs (in-distro names; the `adom-bridge-cli-*` skills are the cloud-side equivalents) - [[hydrogen-eda-discovery-windows]] — the Windows/PowerShell no-bridge install-path + process probe - `pup` — driving fab-vendor upload pages; [hydrogen-open-url](../hydrogen-open-url/SKILL.md) — opening vendor sites - the Adom wiki publish skills — sharing the bridge/app you build with the community
skills/hydrogen-eval/SKILL.md+1−1@@ -1,7 +1,7 @@ --- name: hydrogen-eval description: >- Inject JavaScript into ANY surface of the Hydrogen Desktop window from inside+ Inject JavaScript into ANY surface of the Hydrogen window from inside the workspace — the app shell (top nav, dialogs), the VS Code workbench, the wiki panel, or the Claude chat webview. Backed by the control API's POST /eval-in, which connects directly to the right CDP target and returns the JS
skills/hydrogen-instapcb/SKILL.md+4−4@@ -2,7 +2,7 @@ name: hydrogen-instapcb description: > The playbook a (second, background) Claude conversation runs after setup to wire up the user's- InstaPCB quoting workflow inside Hydrogen Desktop: find any InstaPCB quotes they uploaded+ InstaPCB quoting workflow inside Hydrogen: find any InstaPCB quotes they uploaded earlier, bring one up in the InstaPCB quoting engine in HD, and — if they want — set up a live loop so KiCad design changes auto-import and the quote re-quotes on-the-fly with zero manual steps. Detect + report + offer first; build the watch→reload loop only on a yes. READ@@ -48,11 +48,11 @@ keep). If the app exposes a quote-by-id URL or an import action, use it; otherwi board, I re-export and the quote refreshes — no clicking."* If yes, build the loop: 1. **Watch the KiCad design** — watch the user's `.kicad_pcb` (+ schematic) for saves. Use a- file watcher in the workspace, or `adom-desktop watch` around a poll of the board's mtime- (see `adom-desktop-fusion`'s `watch` wrapper for the streaming pattern).+ file watcher in the workspace, or `adom-bridge-cli watch` around a poll of the board's mtime+ (see `adom-bridge-cli-fusion`'s `watch` wrapper for the streaming pattern). 2. **On change → produce the artifact InstaPCB needs.** Most quoting wants **gerbers** — export them from KiCad (kicad-cli / the PCB editor's plot), staged into `~/project`. (KiCad bridge:- open/drive the board — see `hydrogen-bridges`/`adom-desktop-kicad`.)+ open/drive the board — see `hydrogen-bridges`/`adom-bridge-cli-kicad`.) 3. **Push to the quoting engine + re-quote.** Feed the new gerbers/board to the `instapcb-quote` app (its import/upload path) and trigger a re-quote; if it has no API, drive the upload UI via `pup` and reload. **Reload the quote view** so the user sees the new number appear on its own.
skills/hydrogen-notifications/SKILL.md+6−6@@ -1,12 +1,12 @@ --- name: hydrogen-notifications description: >- How Hydrogen Desktop reaches the user OUTSIDE the window — native OS toast+ How Hydrogen reaches the user OUTSIDE the window — native OS toast notifications + taskbar/dock attention — so the AI can proactively tell the user a long job finished or that it needs them (great for hands-free / away-from-keyboard work). Covers HD's notify handler (levels info|warning|error|emergency, optional <actions> buttons; emergency = a persistent attention request until the user looks)- and how to fire one with the `notify` desktop command / `adom-desktop notify_user`.+ and how to fire one with the `notify` desktop command / `adom-bridge-cli notify_user`. Also the in-app `/ui/toast` (a message INSIDE the HD window) and Pup's browser_alert_window taskbar/dock nudge. The native OS-toast backend is platform-specific (see [[hydrogen-notifications-windows]] for the Windows path);@@ -18,7 +18,7 @@ description: > toast, ui toast, /ui/toast, show a toast in HD, toast inside the window. --- -# Hydrogen Desktop — Notifications (reaching the user outside the window)+# Hydrogen — Notifications (reaching the user outside the window) When the user isn't looking at HD — a long build is running, you've finished a job, or you're **blocked and need them** — you can reach them on the OS level: a native **toast**,@@ -39,7 +39,7 @@ Source: `src-tauri/crates/hd-app/src/notifications.rs` (`handle_notify` → `sho Dispatched via the `notify` message; from the workspace use the AD CLI: ```bash-adom-desktop notify_user '{"title":"Build complete","body":"hd_build_rust finished — exit 0","level":"info"}'+adom-bridge-cli notify_user '{"title":"Build complete","body":"hd_build_rust finished — exit 0","level":"info"}' ``` Payload shape (`NotifyPayload`):@@ -102,7 +102,7 @@ notice — see [hd-recording](../hd-recording/SKILL.md).) For AI-driven browser work, Pup has its own attention nudge: ```bash-adom-desktop browser_alert_window '{"sessionId":"default"}'+adom-bridge-cli browser_alert_window '{"sessionId":"default"}' ``` It **flashes the taskbar / bounces the dock** for that browser window (and brings the page@@ -119,7 +119,7 @@ to front within Chrome) **without stealing foreground focus** — a gentle "look glance-able toast and the spoken answer. Don't spam: one notification per meaningful event. Verify the bridge first-(`adom-desktop ping`) before claiming you notified them.+(`adom-bridge-cli ping`) before claiming you notified them. ## Related skills - [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) — AD is what carries `notify_user` to the host; `ping`/`status` to verify the bridge and the `notify` capability
skills/hydrogen-open-url/SKILL.md+3−3@@ -1,7 +1,7 @@ --- name: hydrogen-open-url description: >- The decision guide for "open a URL / open a website" inside Hydrogen Desktop.+ The decision guide for "open a URL / open a website" inside Hydrogen. When the user says "open ti.com" / "pull up the datasheet page" / "show me that site", HD has SIX distinct ways to do it — a Hydrogen webview tab, an HD browser window, Pup (AI-drivable Chrome), a native desktop browser profile,@@ -111,12 +111,12 @@ The Browser Picker defaults the "Open in a fresh window" toggle ON for auth URLs On `/open-url`, `fresh` pre-seeds that toggle (the picker still shows; add `direct:true` to skip it); `/open-in-profile` opens fresh directly. See `hd-browser-picker`. -**3. Pup** — open and then drive it with `adom-desktop browser_*` verbs+**3. Pup** — open and then drive it with `adom-bridge-cli browser_*` verbs (`browser_open_window`, `browser_navigate`, `browser_screenshot`, `browser_eval`, `browser_reload`, …). Either open the URL directly via Pup, or let the picker route to Pup. See the `pup` skill for the full verb set. ```bash-adom-desktop browser_eval '{"sessionId":"default","js":"document.title"}'+adom-bridge-cli browser_eval '{"sessionId":"default","js":"document.title"}' ``` **6. Headless content** — if you only need to *read* the page, skip the browser
skills/hydrogen-overview/SKILL.md+8−8@@ -1,34 +1,34 @@ --- name: hydrogen-overview description: >- Master index for the platform-generic Hydrogen Desktop skills (the- hd-bootstrap set). Start here to find the right skill for any HD topic.+ Master index for the platform-generic Hydrogen skills (the+ hydrogen-bootstrap set). Start here to find the right skill for any HD topic. These skills are runtime-neutral and apply on every host HD runs on (Windows, macOS, Ubuntu); platform layers add their own *-windows (etc.)- companions. Trigger words: HD skills, hydrogen desktop, what skills, find+ companions. Trigger words: HD skills, hydrogen, what skills, find skill, HD help, HD overview, skill index, HD reference. --- -# Hydrogen Desktop — Skill Index+# Hydrogen — Skill Index -Hydrogen Desktop (HD) is Adom's standalone Tauri v2 app that runs the full+Hydrogen (HD) is Adom's standalone Tauri v2 app that runs the full Hydrogen experience locally. One exe manages your workspace, VS Code, Claude Code, the bridges, and the Adom Wiki — zero cloud dependency. HD runs on Windows, macOS, and Ubuntu. -This index lists the **platform-generic** HD skills (the `hd-bootstrap` set).+This index lists the **platform-generic** HD skills (the `hydrogen-bootstrap` set). Every fact in these skills holds regardless of host OS. Where a topic has host-specific mechanics (e.g. how the workspace is hosted, host networking, host-side recording), the platform layer adds a companion skill — on Windows those are the **`hydrogen-windows-bootstrap`** `*-windows` skills (and equivalents for other platforms). The generic skill cross-references its companion. -## The generic HD skills (hd-bootstrap)+## The generic HD skills (hydrogen-bootstrap) | Skill | What it covers | |---|---| | **hydrogen-adom-auth** | Adom login/logout, session token, profile menu, how auth feeds setup. |-| **hydrogen-adom-desktop** | What HD and Adom Desktop (AD) are and how they work together — AD is your hands on the user's real OS (files, shell, OS screenshots, app launch, bridges). |+| **hydrogen-adom-desktop** | What HD and Adom Bridge (AD) are and how they work together — AD is your hands on the user's real OS (files, shell, OS screenshots, app launch, bridges). | | **hydrogen-adom-menu** | The upper-left Adom logo menu (Settings, Ports, API Explorer, DevTools, Setup/Virgin Reset) + About dialog + version readout. | | **hydrogen-api** | Control API reference. Runtime-neutral endpoints. | | **hydrogen-bridges** | Built-in KiCad/Fusion/Puppeteer bridges + extensible wiki catalog (e.g. Blender) + AD capability list. |
skills/hydrogen-permissions/SKILL.md+2−2@@ -1,7 +1,7 @@ --- name: hydrogen-permissions description: >- Hydrogen Desktop AUTO-GRANTS every webview permission — microphone, camera,+ Hydrogen AUTO-GRANTS every webview permission — microphone, camera, clipboard-read, geolocation, notifications, sensors — so inside HD a webview app NEVER shows a "this site wants to use your microphone/camera/clipboard/location" prompt. READ THIS before building or debugging a webview app that uses getUserMedia / clipboard /@@ -19,7 +19,7 @@ description: > # HD auto-grants every webview permission -Hydrogen Desktop's webview registers a permission handler that returns **ALLOW for every+Hydrogen's webview registers a permission handler that returns **ALLOW for every permission kind** — microphone, camera, clipboard-read, geolocation, notifications, sensors, etc. So **inside HD the user never sees a "this site wants to use your microphone / camera / clipboard / location" dialog.** Webview apps that call `getUserMedia`, read the
skills/hydrogen-self-update/SKILL.md+3−3@@ -1,11 +1,11 @@ --- name: hydrogen-self-update-description: "How the AI keeps the Hydrogen Desktop APP itself (the Windows/macOS frontend, not the workspace) up to date — AI-first, consent-based. Use when asked \"is there an HD update\", \"update Hydrogen Desktop\", \"is my HD current\", \"what version of HD am I on\", \"update the app\", \"new HD version\". Trigger words: HD update, update hydrogen desktop, app update, is HD current, HD version, new version of HD, relaunch to update, self-update."+description: "How the AI keeps the Hydrogen APP itself (the Windows/macOS frontend, not the workspace) up to date — AI-first, consent-based. Use when asked \"is there an HD update\", \"update Hydrogen\", \"is my HD current\", \"what version of HD am I on\", \"update the app\", \"new HD version\". Trigger words: HD update, update hydrogen, app update, is HD current, HD version, new version of HD, relaunch to update, self-update." --- # HD Self-Update — the AI updates the app for you (consent-based) -This is how the **Hydrogen Desktop app itself** (the Windows/macOS shell around your editor)+This is how the **Hydrogen app itself** (the Windows/macOS shell around your editor) stays current. It is NOT the `workspace-updater` (that's the in-distro tooling). It's **AI-first**: there is no nagging button — the AI notices a new HD version, tells you both version numbers, and on your OK downloads + relaunches onto the new version.@@ -27,7 +27,7 @@ Returns `{ current_version, latest_version, update_available, staged, ... }`: ## What to do If `update_available`, **tell the user both versions and ASK** — e.g.:-> "Hydrogen Desktop **vX → vY** is available (already downloaded). Want me to update and relaunch?+> "Hydrogen **vX → vY** is available (already downloaded). Want me to update and relaunch? > Takes a few seconds; this workspace and our chat reconnect right after." On **explicit consent**:
skills/hydrogen-settings/SKILL.md+7−7@@ -1,11 +1,11 @@ --- name: hydrogen-settings description: >- Hydrogen Desktop's Settings dialog and the full preference tree the user can+ Hydrogen's Settings dialog and the full preference tree the user can change — theme, vim mode, launch-on-login, console-on-startup, 3D control style,- font, line numbers, schematic nudge, the embedded Adom Desktop options, and+ font, line numbers, schematic nudge, the embedded Adom Bridge options, and more. READ THIS when the user asks "how do I turn on vim mode", "change the- theme", "make HD launch at startup", "stop Adom Desktop's window popping up",+ theme", "make HD launch at startup", "stop Adom Bridge's window popping up", "switch to blender/solidworks orbit controls", "hide line numbers", "show the console on startup", "make the UI compact", or "where are the settings". Opened from the Adom logo menu → Settings. Trigger words — settings, preferences,@@ -46,18 +46,18 @@ override. Keys are dotted (`section.subsection.name`). | `general.appearance.theme` | `adom-dark` | App-wide theme. Options: `adom-dark`, `adom-light`, `adom-dark-high-contrast`, `adom-light-high-contrast` (→ "change the theme" / "light mode" / "high contrast") | | `general.appearance.user_interface_style` | `standard` | UI compactness: `standard` or `compact` (→ "make the UI more compact") | -### desktop *(Hydrogen Desktop app itself)*+### desktop *(Hydrogen app itself)* | Key | Default | What it does | |---|---|---| | `desktop.show_console_on_startup` | `false` | Show the debug console window when HD starts (→ "show the console on startup") | | `desktop.launch_on_boot` | `true` | Auto-launch HD on login / at startup (→ "make HD launch at startup" / "stop HD launching on login" = set false) | -### adom_desktop *(the embedded Adom Desktop / AD that HD runs)*+### adom_desktop *(the embedded Adom Bridge / AD that HD runs)* When HD is running it takes over AD, so AD's options live here. See [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) for the HD↔AD relationship. | Key | Type / default | What it does | |---|---|---|-| `adom_desktop.open` | action button | "Open Adom Desktop" — brings the AD window to the foreground (persists nothing) |+| `adom_desktop.open` | action button | "Open Adom Bridge" — brings the AD window to the foreground (persists nothing) | | `adom_desktop.auto_approve_when_running` | bool, `true` | While HD runs, keep AD in permanent auto-approve mode (auto-accept AD permission prompts) | | `adom_desktop.show_window_on_launch` | bool, `true` | Show AD's window + taskbar icon when HD launches, so you can see it's running (→ "stop AD's window popping up" = set false) | | `adom_desktop.foreground_hd_on_launch` | bool, `true` | Bring HD to the front on launch; AD still shows in the taskbar but stays behind HD |@@ -98,7 +98,7 @@ extension-specific settings). - **"Turn on vim mode"** → `code.vim_emulation_mode` = true - **"Change the theme / dark mode / high contrast"** → `general.appearance.theme` - **"Make HD launch on login / at startup"** / "don't launch on login" → `desktop.launch_on_boot`-- **"Stop Adom Desktop's window popping up"** → `adom_desktop.show_window_on_launch` = false+- **"Stop Adom Bridge's window popping up"** → `adom_desktop.show_window_on_launch` = false - **"Blender / SolidWorks orbit controls"** → `3d.control_style` - **"Hide line numbers / change code font"** → `code.line_numbers.enabled` / `code.appearance.font.family` - **"Show the console when HD starts"** → `desktop.show_console_on_startup`
skills/hydrogen-setup-steps/SKILL.md+5−5@@ -10,7 +10,7 @@ exact per-platform step list, the workspace-provisioning commands, and the state-file name live in the companion [[hydrogen-setup-steps-windows]] skill (for Windows/WSL2). -When you first launched Hydrogen Desktop (or after a virgin reset), HD ran an+When you first launched Hydrogen (or after a virgin reset), HD ran an install sequence to turn a blank machine into a fully-tooled Adom workspace. The heavy tooling (code-server, gallia, the Adom CLIs, the claude CLI + Code extension, VS Code settings, and all `hd-*` skills) is already BAKED into the@@ -34,10 +34,10 @@ auto-retry. The exact steps and ordering are platform-specific — see | set-env-vars | Set `ADOM_CARBON_URL`, `ADOM_HYDROGEN_URL`, `ADOM_HD_CONTROL_URL`, `VSCODE_PROXY_URI`, `ADOM_DESKTOP_MODE` | | inject-api-key | Write the Adom session token into the workspace so adom-cli works | | configure-vscode | settings.json / trusted-domains / activity-bar are BAKED; re-asserts theme + workbench backstops idempotently, and applies the per-session layout |-| ensure-adom-desktop | Verify the Adom Desktop companion app is running (the relay's desktop bridge) |-| start-relay | Start the adom-desktop relay inside the workspace |+| ensure-adom-bridge-cli | Verify the Adom Bridge companion app is running (the relay's desktop bridge) |+| start-relay | Start the adom-bridge-cli relay inside the workspace | | test-direct-connect | Prove the fast workspace→desktop command path |-| test-relay | Register the relay with Adom Desktop for file streaming (file transfer + shell exec) |+| test-relay | Register the relay with Adom Bridge for file streaming (file transfer + shell exec) | | test-adom-cli | GATE: carbon path + hydrogen-proxy reachability via adom-cli | | claude-auth | The single human gate — restore Claude creds or drive the in-editor Claude.ai sign-in via the native browser Browser Picker; runs LAST before the payoff steps | | ensure-sse | GATE: confirm the editor browser SSE session is connected so Welcome's webview-open doesn't 409 |@@ -48,7 +48,7 @@ auto-retry. The exact steps and ordering are platform-specific — see ### Steps that NO LONGER EXIST (baked into the golden image) These are NOT setup steps anymore — they are baked at image-build time:-`install-gallia`, `install-hd-skills`, `verify-adom-desktop`,+`install-gallia`, `install-hd-skills`, `verify-adom-bridge-cli`, `install-claude-cli`, `install-claude-ext`, `write-vscode-settings`, `set-trusted-domains`, `clean-layout`. If a user asks "what installed gallia / the Claude extension / my skills / VS Code settings", the answer is: **baked
skills/hydrogen-setup/SKILL.md+5−5@@ -9,7 +9,7 @@ description: > rollback, step failed, wipe, reset workspace, keep auth, test setup. --- -# Hydrogen Desktop -- Setup Panel & Virgin Reset+# Hydrogen -- Setup Panel & Virgin Reset This is the platform-generic reference for the HD setup panel and virgin reset. The host-platform specifics (the exact install cascade on Windows/WSL2,@@ -47,7 +47,7 @@ Conceptually the steps fall into these phases: 3. **Wire identity + environment** — set the Adom env URLs, inject the Adom session token, re-assert VS Code config backstops idempotently, apply the per-session layout.-4. **Wire the relay** — verify the Adom Desktop companion app, start the+4. **Wire the relay** — verify the Adom Bridge companion app, start the relay inside the workspace, prove direct-connect and register the relay for file streaming. 5. **Gates + payoff** — gate on adom-cli reachability (carbon +@@ -60,7 +60,7 @@ Conceptually the steps fall into these phases: These are NOT setup steps anymore — they are baked at image-build time and must not be listed or "run": `install-gallia`, `install-hd-skills`,-`verify-adom-desktop`, `install-claude-cli`, `install-claude-ext`,+`verify-adom-bridge-cli`, `install-claude-cli`, `install-claude-ext`, `write-vscode-settings`, `set-trusted-domains`, `clean-layout`. gallia, the Adom CLIs, the claude CLI + Code extension, code-server, settings, and all `hd-*` skills are baked into the golden image. See `hd-golden-image`.@@ -160,10 +160,10 @@ automated test resets. ### test-direct-connect Proves the fast workspace→desktop command path. The CLI auto-probes the host-control API and routes through Adom Desktop's direct connect API.+control API and routes through Adom Bridge's direct connect API. ### test-relay (register relay)-Registers the relay (started by the start-relay step) with Adom Desktop for+Registers the relay (started by the start-relay step) with Adom Bridge for file streaming via the code-server proxy path. This enables `pull_file`, `send_files`, and `shell_execute`.
skills/hydrogen-ui/SKILL.md+4−4@@ -12,14 +12,14 @@ description: > setup panel, Adom menu, HD UI. --- -# Hydrogen Desktop — UI Reference+# Hydrogen — UI Reference ## Window Layout HD's window has these regions (top to bottom, left to right): ### Title Bar-- **Left**: "jlauer12 / Hydrogen Desktop" — shows user + app name+- **Left**: "jlauer12 / Hydrogen" — shows user + app name - **Right**: CPU/RAM badges, window controls (minimize/maximize/close) ### Tab Bar@@ -48,7 +48,7 @@ The main menu, opened by clicking the Adom logo at the top-left. Items are group - **API Explorer...** — opens the control-API endpoint explorer dialog **DESKTOP** (Tauri-only — won't appear in browser-served HD; in order)-- **Adom Desktop** — brings the embedded Adom Desktop window to the foreground (taskbar); bus id `adom-desktop.open`+- **Adom Bridge** — brings the embedded Adom Bridge window to the foreground (taskbar); bus id `adom-bridge-cli.open` - **Zoom** — webview zoom controls (− % +) with persistence across launches - **Fullscreen** — toggle fullscreen - **Console** — show/hide the HD debug console window@@ -129,7 +129,7 @@ CTRL="$(cat ~/.adom/hd-control-url)" Common ids (always `GET /ui/actions` for the live set): `adom-menu.open`/`.close`, **`profile-menu.open`/`.close`**, `ports.open`/`.close`, `settings.open`/`.close`, `api-explorer.open`/`.close`, `browser-picker.open`/`.close`, `about.open`/`.close`,-`adom-desktop.open`, `setup-panel.show`, `virgin-reset.open`, `dashboard.go`,+`adom-bridge-cli.open`, `setup-panel.show`, `virgin-reset.open`, `dashboard.go`, `fullscreen.toggle`, `console.toggle`, `devtools.open`, `dev-toolbar.toggle`, `container.start`/`.stop`/`.restart`.
skills/hydrogen-who-am-i/SKILL.md+3−3@@ -1,6 +1,6 @@ --- name: hydrogen-who-am-i-description: How to answer "who am I and what can I do here?" — the auto-question HD's welcome step injects on first launch. Tells Claude what data sources to pull (Adom session token, adom-cli user/repo/container queries), the Linux-username-vs-Adom-username distinction (everyone is `adom` inside the container), and the template answer that names the user, shows their resources, and explains what HD + the Adom ecosystem can do for them. READ this skill when answering "who am i", "what can i do here", or "what is this environment". Trigger words — who am i, what can I do here, who is this user, welcome question, first AI question, introduce yourself, what is HD, what can hydrogen desktop do, user identity, user introspection, my profile in HD, my repos, my containers, linux username vs adom username, adom username container.+description: How to answer "who am I and what can I do here?" — the auto-question HD's welcome step injects on first launch. Tells Claude what data sources to pull (Adom session token, adom-cli user/repo/container queries), the Linux-username-vs-Adom-username distinction (everyone is `adom` inside the container), and the template answer that names the user, shows their resources, and explains what HD + the Adom ecosystem can do for them. READ this skill when answering "who am i", "what can i do here", or "what is this environment". Trigger words — who am i, what can I do here, who is this user, welcome question, first AI question, introduce yourself, what is HD, what can hydrogen do, user identity, user introspection, my profile in HD, my repos, my containers, linux username vs adom username, adom username container. --- # HD Who Am I — answer the welcome-step prompt coherently@@ -40,7 +40,7 @@ Tell them they have access to a full electronics prototyping ecosystem. Specific - **Build CLIs** — automate workflows from the terminal - **3D viewers** — full 3D component / STEP / GLB viewing in HD (via adom-step / adom-tsci panels) - **Open KiCad or Fusion 360** on their Windows machine — HD bridges to the local apps-- **File transfer** — send/receive files between container and their Windows desktop (`adom-desktop send_files` / `pull_file`)+- **File transfer** — send/receive files between container and their Windows desktop (`adom-bridge-cli send_files` / `pull_file`) - **Talk to their cloud containers** — adom-cli reaches Adom-cloud-hosted containers under their account - **Main AI dev environment** — HD is designed as the primary AI-powered dev surface for hardware + software @@ -49,7 +49,7 @@ Tell them they have access to a full electronics prototyping ecosystem. Specific Adapt this to whatever the user's data is. Don't bullet-dump everything — write it as a warm welcome paragraph followed by capabilities. Use markdown. ```markdown-You're **{user.formatted_name}**, signed in to Adom as **{user.name}** ({user.email}). You're running in **Hydrogen Desktop**, Adom's local AI dev environment, on your Windows machine. The workspace itself is Ubuntu 24.04 with code-server, the `claude` CLI, and the full Adom skill ecosystem (gallia + HD skills) already loaded.+You're **{user.formatted_name}**, signed in to Adom as **{user.name}** ({user.email}). You're running in **Hydrogen**, Adom's local AI dev environment, on your Windows machine. The workspace itself is Ubuntu 24.04 with code-server, the `claude` CLI, and the full Adom skill ecosystem (gallia + HD skills) already loaded. A few quick orientation notes: - Your **Linux username here is `adom`** (not `{user.name}`) — that's intentional, every Adom workspace uses `adom` for consistency. Your Adom identity (`{user.name}`) is what shows up across the Adom ecosystem.
skills/hydrogen-workspace-monitoring/SKILL.md+1−1@@ -1,7 +1,7 @@ --- name: hydrogen-workspace-monitoring description: >- How Hydrogen Desktop monitors and manages the local workspace and code-server.+ How Hydrogen monitors and manages the local workspace and code-server. Covers the 15s workspace state poll, the two health levels (runtime available, workspace Running + code-server reachable), the floaty states, auto-start via setup_and_start, auto-reload of the VS Code iframe, and the lifecycle dialog
skills/hydrogen-workspace-updater/SKILL.md+2−2@@ -1,6 +1,6 @@ --- name: hydrogen-workspace-updater-description: "How Hydrogen Desktop keeps THIS workspace's Adom tooling up to date, and how an Adom employee ships a skill / extension / CLI to EVERY Adom workspace automatically. Use when asked \"how do I get the latest skills or tooling from Adom\", \"how are updates delivered here\", \"what's the reload banner\", \"how do I make a skill that distributes to all Adom users\", \"how do I publish tooling to every workspace\". Trigger words: workspace updater, adom-workspace-updater, latest skills, get updates, how do updates work, auto update, distribute a skill, publish to all users, ship to every workspace, reload banner."+description: "How Hydrogen keeps THIS workspace's Adom tooling up to date, and how an Adom employee ships a skill / extension / CLI to EVERY Adom workspace automatically. Use when asked \"how do I get the latest skills or tooling from Adom\", \"how are updates delivered here\", \"what's the reload banner\", \"how do I make a skill that distributes to all Adom users\", \"how do I publish tooling to every workspace\". Trigger words: workspace updater, adom-workspace-updater, latest skills, get updates, how do updates work, auto update, distribute a skill, publish to all users, ship to every workspace, reload banner." --- # How this workspace stays up to date — and how to ship to every workspace@@ -10,7 +10,7 @@ You don't do anything. A gentle background daemon, **`adom-workspace-updater`**, workspace's Adom tooling current automatically. It runs **~5 minutes after the workspace starts**, then **every ~2 hours** — low-priority and **out-of-band** (it is never part of startup and can't slow or break it). When an update needs the editor reloaded (e.g. a new VS-Code extension landed), Hydrogen Desktop fades in a banner at the top of the editor:+Code extension landed), Hydrogen fades in a banner at the top of the editor: **"<Tool> is ready — click to reload."** Click it. Done. Why a daemon at all? Your workspace is imaged **once at install and never re-imaged** — so