bootstrap
Adom Hydrogen (platform base)
Public Made by Adomby adom
Layer Hydrogen's workspace onto a standard Adom workstation.
← Commit history
Merge PR #39: Layer-boundary sweep: make the platform base platform-agnostic
29 files changed
+185−176
README.md+4−4postinstall.sh+9−7skills/hydrogen-adom-auth/SKILL.md+1−1skills/hydrogen-adom-desktop/SKILL.md+13−13skills/hydrogen-adom-menu/SKILL.md+4−4skills/hydrogen-api/SKILL.md+10−11skills/hydrogen-bridges/SKILL.md+18−17skills/hydrogen-captions/SKILL.md+5−5skills/hydrogen-capture-share/SKILL.md+2−2skills/hydrogen-container-stats/SKILL.md+2−2skills/hydrogen-container/SKILL.md+2−2skills/hydrogen-desktop-sse/SKILL.md+4−4skills/hydrogen-eda-discovery/SKILL.md+6−9skills/hydrogen-eval/SKILL.md+2−2skills/hydrogen-monitor/SKILL.md+3−3skills/hydrogen-naming/SKILL.md+10−7skills/hydrogen-notifications/SKILL.md+17−19skills/hydrogen-open-url/SKILL.md+4−4skills/hydrogen-overview/SKILL.md+7−5skills/hydrogen-permissions/SKILL.md+7−7skills/hydrogen-profile-menu/SKILL.md+11−8skills/hydrogen-self-screenshot/SKILL.md+2−2skills/hydrogen-self-update/SKILL.md+2−2skills/hydrogen-settings/SKILL.md+2−2skills/hydrogen-setup-steps/SKILL.md+13−12skills/hydrogen-setup/SKILL.md+13−10skills/hydrogen-ui/SKILL.md+1−1skills/hydrogen-who-am-i/SKILL.md+5−5skills/hydrogen-workspace-monitoring/SKILL.md+6−6README.md+4−4@@ -23,8 +23,8 @@ adom/core ← the Adom ecosystem (shared with Hydrogen Cl └─ adom/hydrogen-bootstrap ← THIS: Hydrogen runtime skills + editor config ``` -Platform layers depend on this one: `adom/hydrogen-windows-bootstrap` (WSL2)-and `adom/hydrogen-mac-bootstrap` (Lima). This is also the public **reference+Platform layers depend on this one: `adom/hydrogen-windows-bootstrap`+and `adom/hydrogen-mac-bootstrap`. 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@@ -52,8 +52,8 @@ image's Dockerfile (not this package at all).** ### postinstall.sh (deploy bundled skills + environment config) 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`:+system-owned workbench file). Mirrors the config sections of the golden-image+bake script (`bake-hydrogen-setup.sh` in the image repo): 0. Deploy the bundled `hydrogen-*` skills (`skills/` dir → `~/.claude/skills/`) 1. Claude Code CLI (claude.ai installer → `~/.local/bin/claude`)
postinstall.sh+9−7@@ -5,7 +5,7 @@ # adompkg installs apps/skills first, bootstraps (and their postinstall) # last. This hook applies the HD *environment configuration* that isn't a # package: the Claude Code + adom-vscode extensions, and the VS Code / code-server-# settings that make the editor behave like Hydrogen Desktop.+# settings that make the editor behave like Hydrogen. # # What is NOT here, by design: # - the Adom ecosystem (skills hub, distributor search, KiCad/Fusion, pup,@@ -21,8 +21,9 @@ # vendor "am I set up?" path), not only inside the golden-image bake. Re-runs # are safe. The bake runs the exact same command, just earlier. #-# Mirrors the config sections of hd-wsl2-image/image/bake-hydrogen-setup.sh — keep-# the two in lockstep until the bake is rewritten to just install this.+# Mirrors the config sections of the golden-image bake script+# (bake-hydrogen-setup.sh in the image repo) — keep the two in lockstep until+# the bake is rewritten to just install this. set -euo pipefail log() { echo "[hd-bootstrap] $*"; } @@ -78,7 +79,7 @@ done # systemd user session, which is unreliable in the bake env. HD installs + auths # it at runtime via its setup cascade (install-claude-cli + claude-auth), in the # real workspace where the user session works. So the bootstrap leaves Claude to-# HD. Just ensure ~/.local/bin is on PATH (for adompkg + adom-desktop).+# HD. Just ensure ~/.local/bin is on PATH (for adompkg + the Adom CLIs). grep -q '/.local/bin' "$HOME/.bashrc" 2>/dev/null \ || printf 'export PATH="$HOME/.local/bin:$PATH"\n' >> "$HOME/.bashrc" @@ -147,10 +148,11 @@ disable-update-check: true CSCONF # NOTE: the workbench.html IndexedDB seed (trusted domains + activity-bar unpin)-# patches the WSL2 code-server install path and is therefore PLATFORM-SPECIFIC —-# it lives in adom/hydrogen-windows-bootstrap, not here. Mac/Ubuntu layers add their own.+# patches a code-server install path that differs per host and is therefore+# PLATFORM-SPECIFIC — it lives in the platform bootstraps+# (adom/hydrogen-windows-bootstrap etc.), not here. -# 6. API-KEY PERSISTENCE (2026-08-04). /var/run is tmpfs — wiped on EVERY distro+# 6. API-KEY PERSISTENCE (2026-08-04). /var/run is tmpfs — wiped on EVERY workspace # boot — and HD's launch-time re-injection missed every other boot path, so # /var/run/adom/api-key vanished and all in-workspace tools 401'd against # carbon/wiki. Fix is DAEMONLESS: systemd-tmpfiles (declarative, runs during
skills/hydrogen-adom-auth/SKILL.md+1−1@@ -324,7 +324,7 @@ full endpoint reference. ## Cross-references -- **hydrogen-adom-auth-windows** -- host app-data path table + WSL2 specifics+- **hydrogen-adom-auth-windows** -- host app-data path table + host runtime specifics - **hydrogen-ui** -- menu layout, where profile menu lives - **hydrogen-setup** -- bootstrap steps that depend on auth - **hydrogen-settings** -- API Explorer (auth endpoints tab)
skills/hydrogen-adom-desktop/SKILL.md+13−13@@ -33,8 +33,8 @@ open it in KiCad." > **Platform note:** Hydrogen'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-bridge-cli status` rather than assuming it.-> For Windows/WSL2-specific host behavior, see the [[hydrogen-adom-desktop-windows]]-> companion skill.+> For platform-specific host behavior, see your platform bootstrap's companion+> skill ([[hydrogen-adom-desktop-windows]] on Windows). ## Two apps, two jobs @@ -120,16 +120,17 @@ adom-bridge-cli shell_auto_approve '{"duration_secs":0}' # turn auto-approve o When you *don't* need a free-form shell, prefer the **no-escape structured runners** over hand-quoted `shell_execute` (ab ≥ 1.8.50):-`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.)+`adom-bridge-cli run_script '{"interpreter":"<shell>","scriptB64":"<b64>"}'`+— base64 the script so no quoting survives to be mangled. The valid interpreter+names, plus any extra platform-specific structured runners (e.g. an+in-workspace exec verb), are documented in your platform bootstrap's companion+skill. ### Auto-installing missing apps If KiCad or Node.js is missing on the host, Hydrogen can trigger an unattended-install on platforms that support it (see the [[hydrogen-adom-desktop-windows]]-companion for the Windows winget verbs). The triggers: `install_kicad` fires+install on platforms that support it (see your platform bootstrap's companion+for the install mechanics). The triggers: `install_kicad` fires when `kicad_list_versions` returns `errorCode:"kicad_not_installed"`; `install_node` when a `browser_*` call returns `errorCode:"node_not_found"` (Node.js unblocks the Pup bridge).@@ -187,8 +188,8 @@ You (AI in the workspace) - In Hydrogen the relay is started for you by the **`start-relay`** setup step; Hydrogen's built-in bridge and the embedded ab both connect to it. The host-side clients reach your in-workspace relay — the exact networking depends on the runtime- (see the `hydrogen-networking` skill, and the [[hydrogen-adom-desktop-windows]] companion- for the WSL2 loopback-forwarding details).+ (see the `hydrogen-networking` skill, and your platform bootstrap's companion+ for the host loopback-forwarding details). - **Always verify the bridge before acting on the host:** ```bash adom-bridge-cli ping # → {"status":"connected", ...} means a client is reachable@@ -203,8 +204,7 @@ You (AI in the workspace) - **Never kill the host ab process** — the host ab is your relay bridge; killing it severs your control channel (you can't get it back from in here).- (Windows-specific `taskkill` warnings live in the- [[hydrogen-adom-desktop-windows]] companion.)+ (Platform-specific process-kill cautions live in the platform companion.) - **Never hardcode `:9001` as Hydrogen's control API.** `9001` is real — it's ab's liveness beacon that ab probes to detect Hydrogen — but Hydrogen's actual control API is **47084** (use `hd_api`, which reads the discovered port).@@ -222,7 +222,7 @@ workspace itself (editor, files under `/home/adom/project`, the runtime), that's **Hydrogen**. 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)+- [[hydrogen-adom-desktop-windows]] — Windows host specifics (paths, unattended installs, loopback forwarding, process-kill cautions) - [hydrogen-embedded-ad](../hydrogen-embedded-ad/SKILL.md) — how Hydrogen bundles + embeds ab (tray, lifecycle, standalone↔embedded) - [hydrogen-bridges](../hydrogen-bridges/SKILL.md) — the KiCad / Fusion / Puppeteer bridge ecosystem - [hydrogen-file-transfer](../hydrogen-file-transfer/SKILL.md) — send/pull files, browse + watch the host filesystem
skills/hydrogen-adom-menu/SKILL.md+4−4@@ -36,16 +36,16 @@ logo = go straight to the Dashboard.) Source: `EditorNav.svelte` → `.logo-butt | **Ports…** | Configure local host port assignments for Hydrogen services (`SettingsPortsDialog`) | | **API Explorer…** | Browse + test every Hydrogen control-API endpoint (`ApiExplorerDialog`); see **hydrogen-api** | | *— Desktop —* | (desktop-only section, shown when running in Hydrogen/Tauri; in order) |-| **Adom Bridge** | Bring the embedded Adom Bridge window to the foreground (taskbar) — FIRST item in the section |+| **Adom Bridge** | Bring the embedded Adom Bridge window to the foreground — FIRST item in the section | | **Zoom** | −/+ zoom the whole Hydrogen UI (persisted) | | **Fullscreen** | Toggle fullscreen | | **Console** | Show/hide the native Hydrogen debug console window |-| **Developer Tools** | Opens WebView2 DevTools (separate window) — see below |+| **Developer Tools** | Opens webview DevTools (separate window) — see below | | **Dev Toolbar** | Show/hide the Adom Dev Toolbar window (eval-in / shot / Claude control endpoints) | | *— Container —* | (state shown: running/stopped/…) | | **Start / Restart / Stop Container** | Workspace lifecycle (see **hydrogen-workspace-lifecycle**) | | *— Admin —* | |-| **Setup Steps** | Show the setup-steps panel — the setup cascade for the active runtime (16 steps under WSL2); see **hydrogen-setup-steps** / **hydrogen-setup** |+| **Setup Steps** | Show the setup-steps panel — the setup cascade for the active runtime; see **hydrogen-setup-steps** / **hydrogen-setup** | | **Virgin Reset** | Open the virgin-reset panel — wipe + re-run setup (see **hydrogen-setup**) | | **Browser Picker Manager** | Manage saved browser choices per domain (see **hydrogen-browser-picker**) | @@ -59,7 +59,7 @@ Drive it programmatically with **hydrogen-eval** (`target:"shell"`): click The `devtools` capability is compiled into **all** builds (dev and release), so "Open Developer Tools" works for end users too — Hydrogen is a developer tool. It opens-WebView2 DevTools as a **separate top-level window** (a window-bounded Hydrogen+the webview DevTools as a **separate top-level window** (a window-bounded Hydrogen screenshot will NOT show it). Also reachable from the tray menu and via `POST /devtools` (or the `open_devtools` Tauri command). Pair with **hydrogen-eval** to inspect/inject into any panel.
skills/hydrogen-api/SKILL.md+10−11@@ -48,9 +48,9 @@ rewrites it with the live dynamic port every launch. This is the channel for the the live ports map, Claude control, etc. — distinct from `adom-cli` (`ADOM_HYDROGEN_URL` → SSE), which is unchanged for web-hydrogen parity. -> For the host-side ways to discover the port (Hydrogen log/`ports.json`) and the-> host runtime endpoints (`/wsl/*`, `/docker/*`, `/system/reboot`), see the-> [[hydrogen-api-windows]] companion skill.+> For the host-side ways to discover the port (Hydrogen log / the ports file) and the+> runtime-specific host endpoints, see the platform companion skills+> ([[hydrogen-api-windows]] / [[hydrogen-api-mac]]). ## Health & Status @@ -112,9 +112,9 @@ These endpoints manage the active workspace runtime. | GET | `/container/disk` | — | Disk usage inside the workspace | | POST | `/container/restart` | — | Alias for `/container-restart` | -> Runtime-specific endpoints — the WSL `/wsl/*` tables, the legacy Docker-> `/docker/*` tables, and `/volume-delete` (Docker-only) — live in the-> [[hydrogen-api-windows]] companion skill.+> Runtime-specific endpoint tables (including the legacy Docker-only endpoints)+> live in the platform companion skills ([[hydrogen-api-windows]] /+> [[hydrogen-api-mac]]). ## WebView & VS Code @@ -267,8 +267,8 @@ glides it, and can click. Use for demos or when the user should see where the AI | POST | `/app/relaunch-frontend` | — | Relaunch the Hydrogen GUI (kill+respawn) while it is responsive | | POST | `/window/foreground` | — | Bring the Hydrogen window to the foreground (unminimize + focus) | -> Host OS reboot (`/system/*`) is platform-specific — see the-> [[hydrogen-api-windows]] companion skill.+> Host OS reboot (`/system/*`) is platform-specific — see the platform+> companion skills ([[hydrogen-api-windows]] / [[hydrogen-api-mac]]). ## Diagnostics (`/test/*`) @@ -287,9 +287,8 @@ disabled" otherwise). `GET /test/help` self-lists the whole cluster. | POST | `/test/reset-cascade` | — | Delete install-steps.json + emit setup-reset event | | POST | `/test/screenshot-hydrogen-window` | `{...}` | Capture Hydrogen's own window to a PNG file | -> The `/test/probe-dialogs` endpoint (classifies UAC / WSL2-update / MSI /-> Docker-EULA blocker windows) is Windows-specific — see the-> [[hydrogen-api-windows]] companion.+> The `/test/probe-dialogs` endpoint (classifies Windows-only blocker dialogs)+> is Windows-specific — see the [[hydrogen-api-windows]] companion. ## Key Patterns
skills/hydrogen-bridges/SKILL.md+18−17@@ -14,7 +14,7 @@ description: > # Hydrogen -- Bridge Ecosystem -Hydrogen is the bridge between your Docker container and the user's Windows desktop.+Hydrogen is the bridge between your Docker container and the user's desktop. All commands go through the relay at ws://localhost:8765/. ---@@ -104,10 +104,11 @@ each bridge's status. Auto-refreshes every 15 seconds. > **App missing? You can auto-install it.** When the target app isn't installed, > 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+> KiCad and Node.js you can trigger an **unattended install** instead of > asking the user to download: > `adom-bridge-cli desktop_install_kicad '{}'` / `adom-bridge-cli desktop_install_node '{}'`.-> (Fusion 360 cannot be installed programmatically — surface the link for that.)+> (The install mechanism is platform-specific; the verb reports if unsupported.+> Fusion 360 cannot be installed programmatically — surface the link for that.) ### CSS selectors @@ -159,7 +160,7 @@ setTimeout(function() { ## Prerequisites Check connection: `adom-bridge-cli ping` -- returns "pong" if Hydrogen is connected.-If not connected, the user needs to launch Hydrogen on their Windows machine.+If not connected, the user needs to launch Hydrogen on their machine. --- @@ -216,11 +217,11 @@ adom-bridge-cli browser_record_stop '{"sessionId": "default"}' ## KiCad Bridge -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.+Port: default **8771** (adom-bridge-cli registers the live port; see `adom-bridge-cli status`). Requires KiCad to be installed on the user's machine. ```bash-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_board '{"path": "<host path to board.kicad_pcb>"}'+adom-bridge-cli kicad_open_schematic '{"path": "<host 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@@ -259,12 +260,12 @@ adom-bridge-cli kicad_window_info '{}' ## Fusion 360 Bridge -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.+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 machine. ```bash 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_import_step '{"path": "<host path to model.step>"}'+adom-bridge-cli fusion_export_step '{"path": "<host path to output.step>"}' adom-bridge-cli fusion_board_info adom-bridge-cli fusion_electron_run '{"command": "..."}' ```@@ -297,11 +298,11 @@ status` until installed). To use a catalog bridge: ## File Transfer ```bash-# Send file from Docker to Windows desktop+# Send file from Docker to the desktop adom-bridge-cli send_files '{"files": [{"path": "/home/adom/project/output.pdf"}]}' -# Pull file from Windows to Docker-adom-bridge-cli pull_file '{"remotePath": "C:\\Users\\john\\Downloads\\data.csv", "localPath": "/tmp/data.csv"}'+# Pull file from the desktop to Docker (remotePath uses the host's native path convention)+adom-bridge-cli pull_file '{"remotePath": "<host path to data.csv>", "localPath": "/tmp/data.csv"}' ``` ---@@ -315,11 +316,11 @@ adom-bridge-cli notify_user '{"message": "Build complete!", "duration_ms": 5000} # Open URL in user's browser adom-bridge-cli desktop_open_url '{"url": "https://..."}' -# Open folder in Explorer-adom-bridge-cli desktop_open_folder '{"path": "C:\\Users\\john\\project"}'+# Open folder in the OS file manager+adom-bridge-cli desktop_open_folder '{"path": "<host folder path>"}' -# Execute shell command (requires user approval)-adom-bridge-cli shell_execute '{"command": "dir C:\\Github"}'+# Execute shell command in the host's native shell (requires user approval)+adom-bridge-cli shell_execute '{"command": "<host shell command>"}' ``` ---
skills/hydrogen-captions/SKILL.md+5−5@@ -9,7 +9,7 @@ description: > `POST .../current/caption` fallback exists for scripts hitting Hydrogen's API directly). Distinct from toasts (notifications) and TTS (audio). NOTE: a full-DESKTOP overlay (over every window, on top of other apps) exists as a platform-specific companion —- see [[hydrogen-captions-windows]]. Trigger words — caption, on-screen caption, workspace+ see [[hydrogen-captions-windows]] / [[hydrogen-captions-mac]]. Trigger words — caption, on-screen caption, workspace caption, hydrogen caption, screen overlay, screen label, callout, annotate the screen, step label, put text on screen, overlay text, caption command, adom-cli hydrogen caption, walkthrough label, demo callout, status overlay, label the screen, hide@@ -39,7 +39,7 @@ Hydrogen has **two** caption surfaces, each captured by a *different* kind of re | Surface | Command | Renders | Captured by | Use when | |---|---|---|---|---| | **Workspace caption** | `adom-cli hydrogen caption` | **inside the Hydrogen workspace** (webview overlay, web-Hydrogen style) | a recording/screenshot of the **Hydrogen window** (panel/workspace) | the demo is **inside Hydrogen** — captioning the workspace itself |-| **Desktop overlay** | platform-specific (see [[hydrogen-captions-windows]]) | **over the WHOLE desktop**, above every window | a **full-screen / desktop** recording | the demo shows **other apps** (KiCad, Fusion, a browser) or the whole screen |+| **Desktop overlay** | platform-specific (see [[hydrogen-captions-windows]] / [[hydrogen-captions-mac]]) | **over the WHOLE desktop**, above every window | a **full-screen / desktop** recording | the demo shows **other apps** (KiCad, Fusion, a browser) or the whole screen | **Match the caption to the recording.** A `screenshot panel` / workspace capture sees the **webview** content, so it captures the **workspace** caption but NOT a desktop overlay (a@@ -120,16 +120,16 @@ Body: `{text, duration (SECONDS), position, size}`; clear with `{hide:true}`. For a caption that floats over **every window** (above other apps, the whole desktop) — with ids, corners, and normalized x/y placement — Hydrogen provides a native always-on-top, click-through desktop overlay. That surface and its arguments are **platform-specific**;-see **[[hydrogen-captions-windows]]**.+see **[[hydrogen-captions-windows]]** / **[[hydrogen-captions-mac]]**. ## Patterns - **Walkthrough / demo callouts** — drop a `center` caption per step. Combine with a recording so the callouts end up in the finished video. Pair with TTS for narration. - **Status corner / point-at-a-thing** — these need named corners or normalized x/y, which- only the desktop overlay provides; see [[hydrogen-captions-windows]].+ only the desktop overlay provides; see the platform companion. ## Related skills - [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) — the relay that carries caption verbs to the host - `adom-tts` — *audio* narration to pair with on-screen captions (captions are visual-only)-- [[hydrogen-captions-windows]] — the full-desktop always-on-top overlay caption surface+- [[hydrogen-captions-windows]] / [[hydrogen-captions-mac]] — the full-desktop always-on-top overlay caption surface
skills/hydrogen-capture-share/SKILL.md+2−2@@ -29,7 +29,7 @@ auto-approves in ~3s), a brief countdown plays, then you can capture frames. > ab with zero dialogs. This skill is the **in-webview** share that captures what > Hydrogen itself is rendering (the editor) via the browser's `getDisplayMedia`/Element > Capture, gated by an in-app consent dialog. And it is distinct from-> [hydrogen-permissions](../hydrogen-permissions/SKILL.md) (WebView2 auto-granting mic/cam OS+> [hydrogen-permissions](../hydrogen-permissions/SKILL.md) (the webview auto-granting mic/cam OS > permissions) — that's a different layer. ## The Screen Capture dropdown (editor toolbar)@@ -144,5 +144,5 @@ the toast is a real, abortable delay. ## Related skills - [hydrogen-recording](../hydrogen-recording/SKILL.md) — screen/mic recording (same share + countdown machinery; in-app .webm recorder + ab desktop recording) - [hydrogen-self-screenshot](../hydrogen-self-screenshot/SKILL.md) — CDP per-panel screenshots + shotlog visual-verify loop-- [hydrogen-permissions](../hydrogen-permissions/SKILL.md) — WebView2 auto-granting OS mic/cam/notification permissions (a *different* layer from this consent dialog)+- [hydrogen-permissions](../hydrogen-permissions/SKILL.md) — the webview auto-granting OS mic/cam/notification permissions (a *different* layer from this consent dialog) - [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) — ab's dialog-free host OS screenshots (`desktop_screenshot_screen/_window`)
skills/hydrogen-container-stats/SKILL.md+2−2@@ -7,7 +7,7 @@ description: Hydrogen's workspace stats indicator in the top-right of the title The top-right of Hydrogen's title bar (next to the audio/video icons and your profile avatar) shows a tiny `Container` block with two horizontal progress bars — CPU% and RAM% — that animate in real-time. Hovering brings up a tooltip with the full workspace details. The numbers reflect your **local Hydrogen workspace**; the header reads "Container" on all platforms. -> Platform layers add a `*-windows` companion ([[hydrogen-container-stats-windows]]) with the host-specific probe — the WSL `workspace_stats()` health check, `wsl --terminate` restart, the benign `[docker]` log line, and distro disk semantics.+> The platform bootstraps override this skill with the host-specific probe details — the `workspace_stats()` health check, the restart command, benign log signals, and disk semantics. ## How often it polls @@ -70,7 +70,7 @@ When `restart needed` shows, open the Adom menu → Restart Workspace (see the ` - **Two health levels** the probe checks: (1) is the host runtime itself available; (2) is the workspace registered + running with code-server reachable on host port 7380. If either fails, the probe returns a needs-restart signal instead of stats and the UI shows the red "restart needed" badge. - **Rate-limited error logging**: the "needs restart" log line is printed at most once every 30 seconds, even though the frontend polls every 1s, so the log stays readable. -The authoritative "which runtime am I on" log line is `[app] Active workspace runtime: …`. (Platform-specific log signals — e.g. the benign Windows `[docker]` heartbeat — are covered in `[[hydrogen-container-stats-windows]]`.)+The authoritative "which runtime am I on" log line is `[app] Active workspace runtime: …`. (Platform-specific log signals are covered in the platform-specific version of this skill.) ## API access
skills/hydrogen-container/SKILL.md+2−2@@ -7,7 +7,7 @@ description: Context for Claude Code running inside a Hydrogen workspace. Docume You are running inside the **local workspace** managed by Hydrogen (ah). Hydrogen is the flagship Adom desktop app — it manages your workspace, bridges to desktop apps, and provides VS Code + Claude Code. Hydrogen 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.+> The platform bootstraps override this skill with the host-specific spine — how the `Adom-Workspace` workspace is hosted and imported, code-server port forwarding, the runtime source, and the Cloud-vs-local comparison table. ## The workspace — exact facts (don't guess) @@ -123,7 +123,7 @@ adom-bridge-cli desktop_open_folder '{"path": "<host folder path>"}' - `GALLIA_SERVICE=local` — tells gallia this is a local workspace - `VSCODE_PROXY_URI=http://localhost:7380/proxy/{{port}}/` — code-server's proxy -(Platform layers may set additional host-specific env vars — see `[[hydrogen-container-windows]]`.)+(Platform layers may set additional host-specific env vars — see your platform bootstrap's version of this skill.) ## Related skills
skills/hydrogen-desktop-sse/SKILL.md+4−4@@ -5,10 +5,10 @@ description: How Hydrogen's local workspace API + SSE works (a.k.a. the workspac # Hydrogen — Local Workspace API + SSE -> Platform note: Hydrogen runs the same local workspace API on every platform (Windows/WSL2,-> macOS, Linux). For the WSL2-specific networking details (mirrored loopback,-> `%APPDATA%\hydrogen-desktop\ports.json`, the `HD_RUNTIME=docker` runtime, relay-> same-port behavior), see **[[hydrogen-desktop-sse-windows]]**.+> Platform note: Hydrogen runs the same local workspace API on every platform. The+> host-specific networking details (loopback forwarding, the `ports.json` location,+> the legacy runtime modes, relay port behavior) live in the platform companion —+> see **[[hydrogen-desktop-sse-windows]]** on Windows. ## Architecture
skills/hydrogen-eda-discovery/SKILL.md+6−9@@ -32,13 +32,10 @@ adom-bridge-cli fusion_status '{}' # Fusion 360 installed? ("installed 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-bridge-cli run_script`. The exact probe is-platform-specific:--- **Windows:** scan `C:\Program Files` / `C:\Program Files (x86)` and `Get-Process` via a- PowerShell `run_script` — see **[[hydrogen-eda-discovery-windows]]** for the ready-to-run probe.-- **macOS:** scan `/Applications` (and `~/Applications`) for the app bundles, plus `pgrep`.-- **Linux:** `which`/`command -v` the CLI binaries and check common install dirs, plus `pgrep`.+**install path / running process** using `adom-bridge-cli run_script`. The exact probe+(install directories, process listing) is platform-specific — see your platform+bootstrap's EDA companion skill ([[hydrogen-eda-discovery-windows]] on Windows;+`hydrogen-eda-install` in the mac bootstrap) for the ready-to-run probe. (Whatever the platform: treat **empty output as a timeout**, not a negative result.) @@ -102,7 +99,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-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+- [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) / [hydrogen-bridges](../hydrogen-bridges/SKILL.md) — the `adom-bridge-cli` relay + KiCad/Fusion bridge verbs (in-workspace names; the `adom-bridge-cli-*` skills are the cloud-side equivalents)+- [[hydrogen-eda-discovery-windows]] / `hydrogen-eda-install` (mac) — the per-platform no-bridge install-path + process probes - `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+2−2@@ -31,8 +31,8 @@ see "Why two paths" below) and runs your JS there, returning the value. ## Finding the control port + reaching it from the workspace The control API port is **dynamic** (auto-resolves conflicts per launch). From inside-the workspace, reach Hydrogen on `127.0.0.1` (WSL2 mirrored networking shares loopback with the-Windows host). Read the live control URL from the discovery file `~/.adom/hydrogen-control-url`+the workspace, reach Hydrogen on `127.0.0.1` (the workspace shares loopback with the host;+how that works is platform-specific). Read the live control URL from the discovery file `~/.adom/hydrogen-control-url` (your non-interactive Bash shells don't source `.bashrc`/`profile.d`, so the env var alone is unreliable):
skills/hydrogen-monitor/SKILL.md+3−3@@ -33,10 +33,10 @@ Watch the Hydrogen workspace in real-time using Claude Code's Monitor tool + Hyd The proxy SSE stream below is for *reacting continuously*. If you just need a snapshot of current state, the **control port** (`$(cat ~/.adom/hydrogen-control-url)`,-i.e. `http://127.0.0.1:<dynamic>` — same loopback from the workspace and the host-via WSL2 mirrored networking) has cheaper reads:+i.e. `http://127.0.0.1:<dynamic>` — the workspace shares loopback with the host)+has cheaper reads: -- `GET /workspace/health` — deep workspace health (distro + code-server + host reachability)+- `GET /workspace/health` — deep workspace health (workspace + code-server + host reachability) - `GET /workspace/tabs` — list all workspace tabs right now - `GET /workspace/tabs/find?name=X` — does a named tab exist (404 if not)
skills/hydrogen-naming/SKILL.md+10−7@@ -40,12 +40,12 @@ Every OS-visible install surface MUST carry the Formal Name **"Adom Hydrogen"** (and "Adom Bridge" for ab): - Start Menu entry, desktop shortcut, taskbar pin-- Installer product name and artifact filename ("Adom Hydrogen_x.y.z_x64-setup.exe")-- Add/Remove Programs entry, autostart registry value name+- Installer product name and artifact filename+- The OS installed-apps list entry and the autostart entry name - macOS app bundle name / Spotlight -**Why:** a new user will inevitably open Windows taskbar search and type-**"adom"**, not "hydrogen", because they have not memorized the product name+**Why:** a new user will inevitably open their OS app search (taskbar search,+Spotlight) and type **"adom"**, not "hydrogen", because they have not memorized the product name yet. They know they installed something from Adom. If the shortcut says bare "Hydrogen", that search finds NOTHING and the product looks broken or gone. Adom must be in the installed name. That is the entire reason the Formal Name@@ -72,8 +72,11 @@ never does: **hc**, **nb**, **nbe**, **hbw**, **pup**. These deliberately keep old spellings because they are load-bearing state or build identity, renaming them breaks installs: -- Windows state dir `%APPDATA%\hydrogen-desktop` - Bundle identifier `inc.adom.hydrogen-desktop`-- Cargo package `hydrogen-desktop` (the BINARY is `hydrogen.exe`)+- Cargo package `hydrogen-desktop` - GitHub repo `adom-inc/hydrogen-desktop`-- WSL distro `Adom-Workspace`+- Workspace name `Adom-Workspace`++Platform-specific frozen identifiers (the host state-dir path, binary and+installer artifact names) are listed in your platform bootstrap's companion+skill (e.g. [[hydrogen-naming-windows]]).
skills/hydrogen-notifications/SKILL.md+17−19@@ -2,15 +2,15 @@ name: hydrogen-notifications description: > How Hydrogen reaches the user OUTSIDE the window — native OS toast- notifications + taskbar/dock attention — so the AI can proactively tell the user a+ notifications + an OS-level attention request — 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 Hydrogen'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-bridge-cli notify_user`. Also the in-app `/ui/toast` (a message INSIDE the Hydrogen 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);- cross-platform behavior is documented here. Trigger words — notify the user, send a+ browser_alert_window attention nudge. The native OS-toast backend is+ platform-specific (see the platform companions [[hydrogen-notifications-windows]] /+ [[hydrogen-notifications-mac]]); cross-platform behavior is documented here. Trigger words — notify the user, send a notification, desktop notification, toast, os toast, native toast, taskbar flash, dock bounce, get the user's attention, alert the user, notify_user, emergency notification, urgent alert, notification actions, action buttons, ping the user, job done@@ -22,16 +22,14 @@ description: > When the user isn't looking at Hydrogen — 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**,-and for urgent cases a **persistent attention request** (a taskbar flash / dock bounce,-depending on platform). This is what makes hands-free / away-from-keyboard work usable:+and for urgent cases a **persistent attention request** (the exact form is+platform-specific). This is what makes hands-free / away-from-keyboard work usable: don't just print a message into a panel nobody's watching — fire a notification. -> **Platform note:** the native OS toast is delivered by a per-platform backend. The full-> experience (a rich OS toast plus a persistent attention request) is best on Windows-> (WinRT toasts + taskbar attention — see [[hydrogen-notifications-windows]]); macOS has a more-> limited path (an `osascript`-style notification); Linux has no native toast path. The-> `notify_user` API itself is the same everywhere; what differs is how richly the OS-> surfaces it.+> **Platform note:** the native OS toast is delivered by a per-platform backend, and how+> richly the OS surfaces it varies by platform. The `notify_user` API itself is the same+> everywhere. The per-platform delivery mechanics live in the platform companions:+> [[hydrogen-notifications-windows]] and [[hydrogen-notifications-mac]]. ## Firing a notification @@ -65,13 +63,13 @@ Payload shape (`NotifyPayload`): - `info` / `warning` / `error` — a standard toast (warnings and errors stay up longer). - **`emergency`** — in addition to the toast, Hydrogen calls **`request_user_attention(Critical)`** on the main window and shows/unminimizes it. This produces a **persistent attention- request** (a taskbar flash on Windows, a dock bounce on macOS) that **keeps going until- the user actually interacts with the window/taskbar themselves** — it is *not* cleared by+ request** (the OS keeps signaling the app) that **keeps going until+ the user actually interacts with the window themselves** — it is *not* cleared by a programmatic focus. Reserve `emergency` for "I genuinely cannot proceed without you" — it's intentionally hard to ignore. -> The Windows-specific toast identity/title behavior (the AUMID "Adom" title quirk) and the-> WinRT/orange-taskbar-flash details live in [[hydrogen-notifications-windows]].+> Platform-specific toast identity/title behavior and delivery details live in the+> platform companions [[hydrogen-notifications-windows]] / [[hydrogen-notifications-mac]]. ## In-app toast — `POST /ui/toast` (inside the Hydrogen window) @@ -97,7 +95,7 @@ when the user may be **away from / not looking at** Hydrogen; use `/ui/toast` fo status cue while they're working in Hydrogen. (Hydrogen's native recording uses this for its auto-stop notice — see [hydrogen-recording](../hydrogen-recording/SKILL.md).) -## Pup's taskbar/dock nudge (`browser_alert_window`)+## Pup's attention nudge (`browser_alert_window`) For AI-driven browser work, Pup has its own attention nudge: @@ -105,7 +103,7 @@ For AI-driven browser work, Pup has its own attention nudge: adom-bridge-cli browser_alert_window '{"sessionId":"default"}' ``` -It **flashes the taskbar / bounces the dock** for that browser window (and brings the page+It **triggers the OS attention nudge** for that browser window (and brings the page to front within Chrome) **without stealing foreground focus** — a gentle "look here." (Use `browser_focus_window` if you actually want to raise the window.) @@ -124,4 +122,4 @@ Don't spam: one notification per meaningful event. Verify the bridge first ## Related skills - [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) — ab is what carries `notify_user` to the host; `ping`/`status` to verify the bridge and the `notify` capability - [hydrogen-bridges](../hydrogen-bridges/SKILL.md) — the full ab capability list (`notify`, …) and Pup's `browser_alert_window`-- [[hydrogen-notifications-windows]] — the Windows toast backend (WinRT, AUMID "Adom" title, orange taskbar flash)+- [[hydrogen-notifications-windows]] / [[hydrogen-notifications-mac]] — the per-platform toast backends and attention mechanics
skills/hydrogen-open-url/SKILL.md+4−4@@ -51,8 +51,8 @@ keystrokes)."* Say it **once**, not every time (don't nag). This is exactly how ## How you invoke each All of these run from inside the Hydrogen workspace. The control API base URL is the live-value in `~/.adom/hydrogen-control-url` — `http://127.0.0.1:<dynamic>` (WSL2 mirrored-networking shares loopback with the Windows host; the port is dynamic per launch).+value in `~/.adom/hydrogen-control-url` — `http://127.0.0.1:<dynamic>` (the workspace+shares loopback with the host; the port is dynamic per launch). Read it with `BASE="$(cat ~/.adom/hydrogen-control-url)"` then hit `"$BASE/<endpoint>"`. **1. Webview tab (wv)** — add a web-view tab pointed at the URL (`adom-workspace-control`,@@ -104,7 +104,7 @@ Pup; otherwise the user's last choice for that domain. See `hydrogen-browser-pic **Fresh window (`"fresh":true`)** — the native-browser path (#4) can open the URL either as a tab in an already-running browser (default) or as a **brand-new window/-process** (`--new-window`). A freshly-launched window **auto-foregrounds** on Windows;+process** (`--new-window`). A freshly-launched window **auto-foregrounds**; a tab does not. So for **auth flows the user must complete** (Claude/Adom sign-in), prefer `fresh:true` — the consent page comes to the front by itself, no manual focus. The Browser Picker defaults the "Open in a fresh window" toggle ON for auth URLs.@@ -196,4 +196,4 @@ fallback for the genuinely-undecided. - [hydrogen-browser-picker](../hydrogen-browser-picker/SKILL.md) — the interception layers + picker dialog behind #2/#4/#5 - `pup` — driving Pup browser windows (#3): navigate, screenshot, eval, reload - `adom-workspace-control` — adding/managing Hydrogen webview tabs (#1)-- [hydrogen-runtime-mode](../hydrogen-runtime-mode/SKILL.md) — none of this changes between the WSL2 and Docker runtimes+- [hydrogen-runtime-mode](../hydrogen-runtime-mode/SKILL.md) — none of this changes across workspace runtimes
skills/hydrogen-overview/SKILL.md+7−5@@ -12,7 +12,7 @@ description: > # Hydrogen — Skill Index Hydrogen (ah) is Adom's standalone Tauri v2 app that runs the full-Hydrogen experience locally. One exe manages your workspace, VS Code,+Hydrogen experience locally. One app manages your workspace, VS Code, Claude Code, the bridges, and the Adom Wiki — zero cloud dependency. Hydrogen runs on Windows, macOS, and Ubuntu. @@ -43,7 +43,7 @@ for other platforms). The generic skill cross-references its companion. | **hydrogen-instapcb** | InstaPCB integration in Hydrogen. | | **hydrogen-monitor** | Real-time SSE event stream + Monitor-tool patterns for watching workspace mutations. | | **hydrogen-naming** | The naming doctrine: Hydrogen/ah, Bridge/ab, and WHY installers/shortcuts MUST say "Adom Hydrogen" (users search "adom"). |-| **hydrogen-notifications** | Reach the user outside the window — native OS toasts + emergency taskbar flash via `notify_user`. |+| **hydrogen-notifications** | Reach the user outside the window — native OS toasts + an emergency attention request via `notify_user`. | | **hydrogen-open-url** | The decision guide for "open a website" — the ways (webview tab, Hydrogen window, Pup, native browser, picker, headless curl) and when to pick each. | | **hydrogen-overview** | This index. | | **hydrogen-permissions** | Why mic/camera/clipboard/notifications "just work" in Hydrogen — webview permissions are auto-granted, so webview apps see no Allow prompts. |@@ -63,8 +63,10 @@ for other platforms). The generic skill cross-references its companion. ## Platform layers Platform-specific mechanics live in a platform layer that ships alongside this-set and adds `*-windows`-style companion skills (e.g. `hydrogen-container-windows`,-`hydrogen-container-stats-windows`, `hydrogen-networking`, `hydrogen-volume`,+set and adds platform companion skills (suffixed `*-windows` / `*-mac`) or+overrides a same-named skill with its host-specific version (e.g.+`hydrogen-container`, `hydrogen-networking`, `hydrogen-volume`, `hydrogen-workspace-lifecycle`). When a generic skill above has a host-specific detail, it cross-references its companion. On a given host you'll have the generic set-plus that host's platform layer.+plus that host's platform layer (`hydrogen-windows-bootstrap` or+`hydrogen-mac-bootstrap`).
skills/hydrogen-permissions/SKILL.md+7−7@@ -9,8 +9,8 @@ description: > suppressed by design. Distinguish this browser-permission auto-grant from the SEPARATE in-app screen-share / mic consent the AI itself requests (that one IS user-approved — see hydrogen-capture-share). Hydrogen's webview engine is platform-specific; the per-engine- implementation detail (e.g. WebView2 on Windows) lives in the platform companion (see- [[hydrogen-permissions-windows]]). Trigger words — permission, permissions, webview permission,+ implementation detail lives in the platform companion skills (see+ [[hydrogen-permissions-windows]] / [[hydrogen-permissions-mac]]). Trigger words — permission, permissions, webview permission, allow microphone, allow camera, allow clipboard, clipboard read, getUserMedia, mic permission, camera permission, geolocation permission, notifications permission, sensors permission, site wants to use, permission prompt, click allow, no permission prompt,@@ -29,10 +29,10 @@ Every request is unconditionally allowed. In the Hydrogen log you'll see lines l auto-granted permission kind …` and, at startup, `[perm] Registered PermissionRequested auto-grant handler`. -> **Platform note:** Hydrogen uses a different webview engine per platform (e.g. WebView2 on-> Windows, WebKit on mac/Linux). The auto-grant policy is the same everywhere — every-> permission is allowed up front — but the exact engine API is platform-specific. The-> Windows/WebView2 implementation and its code evidence are in [[hydrogen-permissions-windows]].+> **Platform note:** Hydrogen uses a different webview engine per platform. The auto-grant+> policy is the same everywhere — every permission is allowed up front — but the exact+> engine API is platform-specific. The per-platform implementations and their code+> evidence are in [[hydrogen-permissions-windows]] and [[hydrogen-permissions-mac]]. ## Why Hydrogen does this @@ -66,4 +66,4 @@ approval. See `hydrogen-capture-share`. ## Related skills - `hydrogen-capture-share` — the SEPARATE, user-approved screen-share / mic consent the AI requests - [hydrogen-open-url](../hydrogen-open-url/SKILL.md) — opening URLs/webview apps inside Hydrogen (where these permissions apply)-- [[hydrogen-permissions-windows]] — the WebView2 (Windows) implementation + lib.rs evidence+- [[hydrogen-permissions-windows]] / [[hydrogen-permissions-mac]] — the per-platform webview implementations + code evidence
skills/hydrogen-profile-menu/SKILL.md+11−8@@ -40,7 +40,7 @@ Clicking **Log out** opens this dialog: ``` - **Cancel** — dismisses the dialog, you stay signed in-- **Confirm** — wipes `hydrogen-session.txt` from `%APPDATA%\hydrogen-desktop\`, clears in-memory session state, and routes the webview to `/auth/login`+- **Confirm** — wipes the `hydrogen-session.txt` session file from Hydrogen's app-data directory on the host (platform-specific location; see your platform bootstrap), clears in-memory session state, and routes the webview to `/auth/login` After Confirm: you land on the Hydrogen login page and **cannot use Hydrogen until you log in again.** @@ -64,15 +64,18 @@ After successful login, Hydrogen restores you to the route you were trying to re | Confirm button | `.confirm-dialog .confirm-btn`, `button:has-text("Confirm")` | | Cancel button | `.confirm-dialog .cancel-btn`, `button:has-text("Cancel")` | -```bash-# Open profile menu-echo "document.querySelector('.profile-dropdown-button')?.click()" | node C:\Users\john\hydrogen-cdp.js+Run these snippets in the shell surface via `POST /eval-in {target:"shell", js:"..."}`+(see [hydrogen-eval](../hydrogen-eval/SKILL.md)): -# Trigger logout-echo "Array.from(document.querySelectorAll('.dropdown-link')).find(e => e.textContent.includes('Log out'))?.click()" | node C:\Users\john\hydrogen-cdp.js+```js+// Open profile menu+document.querySelector('.profile-dropdown-button')?.click() -# Confirm logout (after dialog appears)-echo "Array.from(document.querySelectorAll('button')).find(b => b.textContent.trim() === 'Confirm')?.click()" | node C:\Users\john\hydrogen-cdp.js+// Trigger logout+Array.from(document.querySelectorAll('.dropdown-link')).find(e => e.textContent.includes('Log out'))?.click()++// Confirm logout (after dialog appears)+Array.from(document.querySelectorAll('button')).find(b => b.textContent.trim() === 'Confirm')?.click() ``` ## Related skills
skills/hydrogen-self-screenshot/SKILL.md+2−2@@ -79,7 +79,7 @@ is affected** — the CDP path coexists. Hydrogen makes this deterministic: |---|---|---| | ONE panel or webview tab (the welcome page, a viewer, the editor) | `adom-cli hydrogen screenshot panel …` | `panel` | | The whole Hydrogen **workspace** (every panel side by side) | `adom-cli hydrogen screenshot workspace` | `workspace` |-| The whole **screen** — desktop, taskbar, OTHER apps | `adom-cli hydrogen screenshot screen` | `screen` |+| The whole **screen** — desktop, OTHER apps | `adom-cli hydrogen screenshot screen` | `screen` | **"My whole screen / my desktop / my monitor / everything"** → `adom-cli hydrogen screenshot screen`. The Hydrogen `screen` scope captures the real desktop and saves the PNG into@@ -92,7 +92,7 @@ your container, same as the others. adom-cli hydrogen screenshot workspace # → prints screenshots/<ts>.png (relative to ~/project) → Read ~/project/screenshots/<ts>.png -# Whole screen / desktop (other apps, taskbar):+# Whole screen / desktop (other apps too): adom-cli hydrogen screenshot screen --reason "show the desktop" # A specific panel / webview tab. Tab names are whatever the USER has open — DON'T
skills/hydrogen-self-update/SKILL.md+2−2@@ -1,11 +1,11 @@ --- name: hydrogen-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 Hydrogen update\", \"update Hydrogen\", \"is my Hydrogen current\", \"what version of Hydrogen am I on\", \"update the app\", \"new Hydrogen version\". Trigger words: Hydrogen update, update hydrogen, app update, is Hydrogen current, Hydrogen version, new version of Hydrogen, relaunch to update, self-update."+description: "How the AI keeps the Hydrogen APP itself (the desktop frontend, not the workspace) up to date — AI-first, consent-based. Use when asked \"is there an Hydrogen update\", \"update Hydrogen\", \"is my Hydrogen current\", \"what version of Hydrogen am I on\", \"update the app\", \"new Hydrogen version\". Trigger words: Hydrogen update, update hydrogen, app update, is Hydrogen current, Hydrogen version, new version of Hydrogen, relaunch to update, self-update." --- # Hydrogen Self-Update — the AI updates the app for you (consent-based) -This is how the **Hydrogen app itself** (the Windows/macOS shell around your editor)+This is how the **Hydrogen app itself** (the desktop 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 Hydrogen version, tells you both version numbers, and on your OK downloads + relaunches onto the new version.
skills/hydrogen-settings/SKILL.md+2−2@@ -59,8 +59,8 @@ When Hydrogen is running it takes over ab, so ab's options live here. See |---|---|---| | `adom_desktop.open` | action button | "Open Adom Bridge" — brings the ab window to the foreground (persists nothing) | | `adom_desktop.auto_approve_when_running` | bool, `true` | While Hydrogen runs, keep ab in permanent auto-approve mode (auto-accept ab permission prompts) |-| `adom_desktop.show_window_on_launch` | bool, `true` | Show ab's window + taskbar icon when Hydrogen launches, so you can see it's running (→ "stop ab's window popping up" = set false) |-| `adom_desktop.foreground_hd_on_launch` | bool, `true` | Bring Hydrogen to the front on launch; ab still shows in the taskbar but stays behind Hydrogen |+| `adom_desktop.show_window_on_launch` | bool, `true` | Show ab's window when Hydrogen launches, so you can see it's running (→ "stop ab's window popping up" = set false) |+| `adom_desktop.foreground_hd_on_launch` | bool, `true` | Bring Hydrogen to the front on launch; ab stays visible but behind Hydrogen | ### schematic *(Schematic Workspace)* | Key | Default | What it does |
skills/hydrogen-setup-steps/SKILL.md+13−12@@ -7,8 +7,7 @@ description: What Hydrogen's setup steps did to prepare your workspace — the i This is the platform-generic, user-facing Q&A about what Hydrogen's setup did. The 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).+state-file name live in your platform bootstrap's version of this skill. When you first launched Hydrogen (or after a virgin reset), Hydrogen ran an install sequence to turn a blank machine into a fully-tooled Adom workspace.@@ -21,8 +20,8 @@ failed steps, or wipe and rebuild. See `hydrogen-golden-image` for the baked-ima model. The cascade is halt-on-failure, resume-not-restart, with per-step 3x-auto-retry. The exact steps and ordering are platform-specific — see-[[hydrogen-setup-steps-windows]].+auto-retry. The exact steps and ordering are platform-specific — see your+platform bootstrap's version of this skill. ## The setup state machine — what each phase does @@ -67,8 +66,8 @@ status. failures: the provision step (runtime unavailable, or the golden-image download), test-adom-cli (carbon/hydrogen-proxy not reachable yet), and claude-auth (Claude credentials expired). Each step has a retry button (and the-cascade already retried it 3x). Platform-specific failure causes are in-[[hydrogen-setup-steps-windows]].+cascade already retried it 3x). Platform-specific failure causes are in your+platform bootstrap's version of this skill. **"Re-run a single step"** → In the setup panel, click the step row and use the Re-run action. Or via API: `POST http://127.0.0.1:47084/setup/step/<id>`@@ -99,9 +98,9 @@ which artifacts to delete (option keys in parentheses): queued and flushed at the next Hydrogen launch (restart_required), not immediate. CRITICAL: the workspace reset ONLY ever wipes Hydrogen's own workspace. It never-touches other workspaces, distros, or runtimes the user may have on the+touches other workspaces or runtimes the user may have on the machine, and it performs NO reboot for the wipe. The platform-specific wipe-commands are in [[hydrogen-setup-steps-windows]].+commands are in your platform bootstrap's version of this skill. ## Setup panel APIs (useful for AI automation) @@ -114,8 +113,9 @@ commands are in [[hydrogen-setup-steps-windows]]. All on Hydrogen's control API at `http://127.0.0.1:47084`. -**DEPRECATED — now REFUSED, do not use:** `POST /wsl/unregister`,-`POST /setup/virgin-reset`, `POST /setup/run-all`, `POST /setup/run-step`. Use+**DEPRECATED — now REFUSED, do not use:** `POST /setup/virgin-reset`,+`POST /setup/run-all`, `POST /setup/run-step` (plus deprecated runtime-specific+endpoints listed in your platform bootstrap). Use `POST /setup/panel/run-virgin-reset` and `POST /setup/step/<id>` instead. ## Setup state file@@ -123,11 +123,12 @@ All on Hydrogen's control API at `http://127.0.0.1:47084`. Setup writes its state to a per-step state file (one entry per step with `status: pending|running|done|failed`, output text, percent complete). Hydrogen reads this on launch to decide whether the setup panel auto-opens. The exact file-name and location are platform-specific — see [[hydrogen-setup-steps-windows]].+name and location are platform-specific — see your platform bootstrap's+version of this skill. ## Related skills -- [[hydrogen-setup-steps-windows]] — the concrete WSL2 16-step cascade, the import step, `wsl --unregister`, `setup-steps-wsl.json`, and the golden tarball+- your platform bootstrap's `hydrogen-setup-steps` — the concrete per-platform cascade, provisioning/wipe commands, state file, and the golden tarball - `hydrogen-golden-image` — the baked-image model: what's pre-installed vs. what setup does - `hydrogen-setup` — the setup-panel UX and virgin-reset toggles - `hydrogen-browser-picker` — used by claude-auth for the Claude auth OAuth flow
skills/hydrogen-setup/SKILL.md+13−10@@ -12,9 +12,9 @@ description: > # Hydrogen -- Setup Panel & Virgin Reset This is the platform-generic reference for the Hydrogen setup panel and virgin-reset. The host-platform specifics (the exact install cascade on Windows/WSL2,-distro import/unregister mechanics, the per-platform step list and state file)-live in the companion [[hydrogen-setup-windows]] skill.+reset. The host-platform specifics (the exact install cascade, workspace+import/unregister mechanics, the per-platform step list and state file)+live in your platform bootstrap's version of this skill. ## Zero-Click Goal @@ -33,7 +33,8 @@ The setup cascade is a halt-on-failure, resume-not-restart sequence with per-step 3x auto-retry. State is tracked per-step (status pending / running / done / failed, output text, percent complete) and Hydrogen reads it on launch to decide whether the setup panel auto-opens. The exact step list, ordering, and-state-file name are platform-specific — see [[hydrogen-setup-windows]].+state-file name are platform-specific — see your platform bootstrap's version+of this skill. Conceptually the steps fall into these phases: @@ -107,9 +108,9 @@ creds first UNLESS `claude_token` is checked. The `webview_storage` / (restart_required), NOT immediate; there is no reboot for the wipe. CRITICAL — the virgin reset only ever touches Hydrogen's OWN workspace. It NEVER-touches other workspaces, distros, or runtimes the user may have on the+touches other workspaces or runtimes the user may have on the machine. The platform-specific commands (and the never-touch-global rule)-are in [[hydrogen-setup-windows]].+are in your platform bootstrap's version of this skill. ## Automated Testing Pattern @@ -140,8 +141,9 @@ curl -X POST http://127.0.0.1:47084/setup/step/test-direct-connect \ ``` DEPRECATED — do NOT use these; they are now REFUSED (deprecated headless-triggers): `POST /wsl/unregister`, `POST /setup/virgin-reset`,-`POST /setup/run-all`, `POST /setup/run-step`.+triggers): `POST /setup/virgin-reset`, `POST /setup/run-all`,+`POST /setup/run-step` (plus deprecated runtime-specific endpoints listed in+your platform bootstrap). ## Key Steps Explained @@ -151,7 +153,7 @@ provisions the workspace from the full pre-baked golden image, creates the workspace user, starts code-server, and verifies host loopback reachability. This single step replaces the old pull-image / create-instance / start-instance trio. Platform-specific provisioning commands and any-runtime-install reboot are in [[hydrogen-setup-windows]].+runtime-install reboot are in your platform bootstrap's version of this skill. ### inject-api-key Writes the Adom session token into the workspace so adom-cli works. Requires@@ -189,4 +191,5 @@ When the workspace is wiped and re-provisioned (step 1), the new workspace is a fully pre-baked image. Host port-forwarding for code-server is handled by the runtime, so the port-conflict / stale-mapping class of bug does not apply. Other services tunnel through the code-server `/proxy/{port}/` path. The-platform-specific port-forwarding behavior is in [[hydrogen-setup-windows]].+platform-specific port-forwarding behavior is in your platform bootstrap's+version of this skill.
skills/hydrogen-ui/SKILL.md+1−1@@ -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 Hydrogen; in order)-- **Adom Bridge** — brings the embedded Adom Bridge window to the foreground (taskbar); bus id `adom-bridge-cli.open`+- **Adom Bridge** — brings the embedded Adom Bridge window to the foreground; bus id `adom-bridge-cli.open` - **Zoom** — webview zoom controls (− % +) with persistence across launches - **Fullscreen** — toggle fullscreen - **Console** — show/hide the Hydrogen debug console window
skills/hydrogen-who-am-i/SKILL.md+5−5@@ -39,8 +39,8 @@ Tell them they have access to a full electronics prototyping ecosystem. Specific - **Build apps** — wiki webview apps via the app-creator skill - **Build CLIs** — automate workflows from the terminal - **3D viewers** — full 3D component / STEP / GLB viewing in Hydrogen (via adom-step / adom-tsci panels)-- **Open KiCad or Fusion 360** on their Windows machine — Hydrogen bridges to the local apps-- **File transfer** — send/receive files between container and their Windows desktop (`adom-bridge-cli send_files` / `pull_file`)+- **Open KiCad or Fusion 360** on their computer — Hydrogen bridges to the local apps+- **File transfer** — send/receive files between container and their 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** — Hydrogen 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**, 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 + Hydrogen 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 machine. The workspace itself is Ubuntu 24.04 with code-server, the `claude` CLI, and the full Adom skill ecosystem (gallia + Hydrogen 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.@@ -59,7 +59,7 @@ Here's what we can do together in Hydrogen: **Electronics & hardware** - Build PCBs end-to-end (tscircuit → KiCad → Adom's autorouter → InstaPCB fab)-- Open KiCad or Fusion 360 on your Windows machine directly from here+- Open KiCad or Fusion 360 on your machine directly from here - Browse parts (DigiKey, Mouser, JLCPCB) with live pricing + Adom-internal inventory - Generate KiCad symbols, footprints, and 3D models from datasheets @@ -70,7 +70,7 @@ Here's what we can do together in Hydrogen: **Talk to your stuff** - Reach your cloud Adom containers from here-- Send and pull files between this workspace and your Windows desktop+- Send and pull files between this workspace and your desktop - Drive Chrome via Puppeteer for browser automation - Take screenshots, record videos of your screen
skills/hydrogen-workspace-monitoring/SKILL.md+6−6@@ -17,7 +17,7 @@ description: > This is the platform-generic reference for how Hydrogen monitors workspace health. The host-platform specifics (the runtime-unavailable floaty wording, the stop command, the exact code-server reachability port, and the no-daemon framing)-live in the companion [[hydrogen-workspace-monitoring-windows]] skill.+live in your platform bootstrap's version of this skill. ## Architecture @@ -70,8 +70,8 @@ etc.) remains fully interactive. (which walks the user through enabling the runtime) - **Color**: Red dot in header -The exact runtime name and floaty message are platform-specific — see-[[hydrogen-workspace-monitoring-windows]].+The exact runtime name and floaty message are platform-specific — see your+platform bootstrap's version of this skill. ### 2. Workspace Stopped / Not Ready (red dot) - **When**: the runtime is available but the workspace isn't Running, or it's@@ -138,8 +138,8 @@ and stops. | `toggle_console` | Show/hide the debug console window | | `is_console_visible` | Returns true if console window exists | -The exact stop command is platform-specific — see-[[hydrogen-workspace-monitoring-windows]].+The exact stop command is platform-specific — see your platform bootstrap's+version of this skill. ## Menu Items (Adom Menu → Workspace Section) - **Restart Workspace** — stop the workspace + re-ensure code-server; emits@@ -154,7 +154,7 @@ The exact stop command is platform-specific — see ## Related skills -- [[hydrogen-workspace-monitoring-windows]] — the WSL2 "Not Available" floaty, `wsl --terminate` stop, the 7380 reachability check, the no-daemon framing+- your platform bootstrap's `hydrogen-workspace-monitoring` — the runtime-specific floaty wording, stop command, reachability check, and no-daemon framing - `hydrogen-workspace-lifecycle` — provision/export/remove/stop, the never-touch-global rule, control endpoints - `hydrogen-container-stats` — the title-bar CPU/RAM bars and `workspace_stats()` probe - `hydrogen-networking` — code-server port, control port