Hydrogen Desktop Bootstrap (apps + skills)
Public Made by Adomby adom
Layer Hydrogen Desktop's workspace onto a standard Adom workstation.
Skills
The skills this repo ships, by tier, each with a quick health read. Install the user skills with:
adom-wiki skills install adom/hd-bootstrapAdom auth in HD — how login/logout works (auth intent flow), where the session token lives, the profile menu, and how the Adom session feeds the setup steps. For Claude Code auth specifically, see hd-claude-auth. READ when troubleshooting Adom login failures, session token expiry, the profile dropdown, or virgin-reset Adom-auth options. Trigger words — adom login, login, logout, auth, session token, auth intent, confirmation code, profile menu, avatar, sign in, sign out, hydrogen-session.txt, auth proxy, clear session, HD adom login, Your profile, Your repositories.
What Hydrogen Desktop (HD) and Adom Desktop (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 Windows machine (macOS/Linux coming soon) to create files & folders, run shell commands, take OS screenshots, launch apps, open browsers (Pup / native), and drive KiCad / Fusion 360. HD bundles AD during install and runs it in embedded mode, but AD is a standalone product that ALSO connects Adom cloud containers to a user's machine. HD also has a BUILT-IN desktop bridge of its own that serves a subset of AD's verbs. READ THIS to understand your reach beyond the workspace and how to invoke it. Trigger words — adom desktop, AD, ad cli, what can you do on my computer, reach my machine, create a file on my pc, make a folder on my desktop, run a command 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.
The Adom menu — the logo dropdown in the UPPER-LEFT corner of Hydrogen Desktop (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, 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 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 hd-profile-menu. Trigger words: adom menu, logo menu, upper left menu, hamburger menu, settings, ports, api explorer, developer tools, devtools, dev toolbar, adom desktop, about, about dialog, what version, build info, setup steps menu, virgin reset menu, browser picker, console, fullscreen, zoom.
Complete reference for Hydrogen Desktop control API endpoints. The control API runs on a dynamic port (find it in the HD log or via port discovery). Use these endpoints to drive HD programmatically: manage the workspace runtime (WSL2 distro or legacy Docker container), control Claude Code, manipulate VS Code, manage workspace tabs, run setup steps, trigger virgin reset, and more. ~200 endpoints. The COMPLETE, always-current catalog is GET /_manifest (every route with a category + description; curated entries are richer). The API Explorer window (Adom menu > API Explorer, or POST /api-explorer/open) renders it with a runnable Try per endpoint. GET /test/help lists the gated /test/* diagnostics. NEVER blind-call destructive endpoints (see the Safety section). Trigger words: HD API, control API, HD endpoint, container exec, claude api, iframe eval, workspace tabs, setup run-all, docker status, reload vscode, browser profiles, open url, virgin reset api, reboot api, diagnostics, ad health, test window-tree, ai cursor, setup panel, screenshot mode.
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 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 -- screenshot, desktop screenshot, list windows, capture screen, kicad, fusion, browser, puppeteer, pup, send file, pull file, notify, desktop, bridge, bridge manager, bridge status, bridge install.
HD's Browser Picker — the canonical handler for EVERY URL that gets opened inside HD. Click a link anywhere (main page, code-server iframe, webview panel, PortMappingsDialog, OAuth redirect, localhost link, external link) and HD intercepts it via 5 layers (on_new_window / on_navigation / NewWindowRequested / AddScriptToExecuteOnDocumentCreated / ContextMenuRequested) and routes it through the BrowserProfileDialog so the user (or an AI driving automation) picks where it opens — native browser profile, Hydrogen tab, HD window, or Pup. 5-second auto-countdown so AIs don't block waiting on a click. Read BEFORE adding a URL-opening feature, debugging dead links, fixing `shell.open not allowed`, or automating browser interactions from HD. Trigger words — browser picker, BrowserProfileDialog, hd-open-url, hd-open-url-force, open with browser picker, shell.open not allowed, shell:default, shell:allow-open, plugin-shell, url interception, link click, target blank, claude auth url, adom auth url, oauth callback in browser, default browser, browser profile, AI browser automation, countdown picker, auto-timer, shift click force, right-click open with, context menu, webview links, on_new_window, hd-links (legacy name).
Paint labeled caption text on screen for demos/walkthroughs — captions are CAPTURED BY RECORDINGS so they show up in the finished video. HD has TWO caption surfaces: (1) a WORKSPACE caption rendered inside the HD window via `adom-cli hydrogen caption` — THE default, identical on web-Hydrogen AND HD (text positional; `-d` duration in SECONDS not ms; 30s auto-expire by default, 5-min hard cap, newest-wins, `hide` to clear; a raw-HTTP `POST .../current/caption` fallback exists for scripts hitting HD's API directly), and (2) a full-DESKTOP overlay over ALL windows via `adom-desktop desktop_caption` — HD's built-in Win32 always-on-top, click-through overlay (duration in MILLISECONDS — opposite unit). Pick by what you're recording: workspace recording → workspace caption; whole-screen / other-apps (KiCad, browser) recording → desktop overlay. Covers both, the desktop-overlay args (text, id, position top/center/bottom/corners, normalized x/y, size/fontSize, duration, action: hide|force-clear) and the id rule (same id replaces, different ids coexist). Windows-only for the desktop overlay. Distinct from toasts (notifications) and TTS (audio). 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, always on top text, click-through overlay, desktop caption, caption command, adom-cli hydrogen caption, walkthrough label, demo callout, status overlay, label the screen, point at the screen, hide caption, clear captions, step 3 callout, caption duration, caption seconds, caption auto-expire, caption stuck on screen, caption units, caption position, caption size, persist caption.
The in-HD screen-share + AI-consent surface that lets YOU (the AI) screenshot the editor or the whole screen into the container. Covers the Screen Capture dropdown in the editor toolbar (Share this tab / Share entire screen / Stop sharing, plus Workspace / Full-screen screenshot), the Webview-vs-Pup Window mode toggle, the panel/workspace/screen capture scopes + Element-Capture RestrictionTarget, and the AI sharing-approval flow: SharingApprovalDialog ("AI wants access" + your reason), the ~3s auto-approve in HD, and the cancelable CountdownToast before capture starts. READ THIS before trying to screenshot the editor — a screenshot of HD's own UI requires an active share. Trigger words — screen share, share this tab, share screen, screen capture dropdown, capture the editor, screenshot the workspace, workspace screenshot, AI wants access, sharing approval, consent dialog, countdown toast, start sharing, stop sharing, window mode, webview vs pup, RestrictionTarget, element capture, capture scope, panel screenshot, capture frame, share with the AI.
How Claude Code authenticates inside HD — the OAuth flow that opens in your browser via the Browser Picker, where credentials are stored on host vs container, how HD backs them up so a container rebuild doesn't make you re-auth, the virgin-reset toggle that wipes Claude creds, and the 4-technique auth cascade HD runs if Claude isn't authenticated. READ when troubleshooting "Claude not authenticated", expired Claude tokens, re-authenticating after a virgin reset, or wondering where Claude credentials live. Trigger words — claude auth, claude code login, claude code authentication, claude not authenticated, claude oauth, claude credentials, claude session, claude.ai subscription, replay-claude-credentials.json, claude-auth, claude credential backup, claude re-auth, claude expired, claude.ai subscription button.
First-class API for managing the Claude Code conversations inside Hydrogen Desktop: list/open/close/switch conversation tabs, read each conversation's full state (title, message count, compose box, and the on-disk session GUID), type messages into a SPECIFIC conversation (instant or with a human typing animation) and submit them, and turn on Remote Control to get a claude.ai cloud URL so the user can view+drive that exact conversation from claude.ai or the Claude mobile app. Every conversation is addressed by a stable execution-context id (deterministic, background, no foreground/focus needed). Also explains how a live conversation is matched to its ~/.claude/projects/*.jsonl log. Trigger words: claude tabs, claude conversations, list conversations, open claude tab, close claude tab, switch claude tab, new conversation, type into claude, inject prompt, remote control, claude.ai url, view on mobile, session id, conversation guid, jsonl, claude session, context_id, multi-tab claude, conversation management.
THE recipe for recording a demo video of Hydrogen Desktop: screen-record an AI prompt being TYPED (visible human-jitter typing) into a Claude tab plus the AI's resulting output, then speed the footage 10x to 30x in video-post and lay an adom-tts voiceover on top, so a viewer sees exactly what using an app in HD feels like. Covers the whole pipeline end to end: driving HD's control API (in-workspace OR from a remote container via adom-desktop hd_api), the high-fps native recorder, multi-tab multi-prompt demos, getting the mp4 out (streamed binary, never base64), and the post-production handoff. Trigger words: demo video, record a demo, hd demo, demo recording, record the typing, screen record hd, record ai prompt, app demo, demo pipeline, speedup demo, tts overlay demo, show what the app feels like, hd-demo-recording.
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. The workspace is the WSL2 Adom-Workspace distro by default (or a Docker container under HD_RUNTIME=docker). Covers the full pipeline, routing, env vars, field format differences, 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.
The onboarding playbook a (second, background) Claude conversation runs after HD setup to discover which EDA / electronics-design tools the user runs — KiCad, Fusion 360, Altium, OrCAD/Cadence — and onboard them into the AI-first electronics workflow. If KiCad/Fusion (we have bridges): remember their preferred tool in a prefs file, offer to open example files, and pitch the gerber-export → order-at-JLCPCB/PCBWay/OSHPark loop. If Altium/OrCAD (no bridge yet): pitch co-building a bridge with the AI and publishing it to the Adom wiki for the community (KiCad/Fusion bridges are the reference). READ + RUN this when a new thread is asked to "explore what EDA software I use" / on the post-setup discovery pass. Trigger words — eda discovery, what eda software, what cad do i use, electronics design tools, detect kicad, detect fusion, detect altium, detect orcad, onboard eda, pcb workflow, order pcb, gerbers, jlcpcb, pcbway, oshpark, write a bridge, altium bridge, orcad bridge, publish to adom wiki, ai-first electronics, who am i and what can i do, post-setup explore.
The Editor State Machine (ESM) — HOW to know the true state of the VS Code editor and the Claude Code conversations inside Hydrogen Desktop, and the HARD typing invariants. Use BEFORE typing into a Claude conversation, driving setup-step threads, diagnosing "state unknown", empty split panels, tab spam, prompts landing in the wrong conversation, or any Claude tab/webview confusion. Trigger words — editor state, /editor/state, claude tab state, conversation state, which tab is active, empty editor group, split panel, double-type, typed into two boxes, prompt in wrong conversation, census, safe to type, stray text, disk verified, msg_count wrong, workbench unknown.
How Hydrogen Desktop (HD) and Adom Desktop (AD) interact via "embedded mode". Use whenever the user asks about the system tray icon, why AD isn't visible, why two desktop apps are installed, the "Embedded · HD" footer pill, or how to make AD show up standalone. Trigger words — embedded mode, system tray, AD tray, why is adom desktop hidden, where's my tray icon, HD vs AD, both apps installed, why two installs, ad missing from tray, switch AD to standalone, AD won't show, run AD without HD, decouple AD from HD.
Inject JavaScript into ANY surface of the Hydrogen Desktop 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 value. Use it to build add-ons (e.g. a usage meter in the top bar), demo overlays (a moving arrow that points at things), highlight elements, read DOM state, or drive the UI. Works in dev AND release builds. Trigger words: eval-in, inject ui, eval into hd, hd overlay, demo arrow, highlight element, add-on, addon, usage meter, inject script, target shell, target workbench, target claude, find probe, eval-in targets, point at element, nav widget.
Move files BOTH WAYS between the HD WSL2 Ubuntu workspace (the Adom-Workspace distro, where your code lives at /home/adom/project) and the user's Windows PC — including their Desktop, Downloads, and any folder. Three methods: (1) the auto-mounted C: drive at /mnt/c inside the distro, (2) the \\wsl$ network path from Windows Explorer, and (3) the adom-desktop relay (send_files / pull_file) which also works on the legacy Docker runtime. Use when the user asks "how do I get this file onto my desktop", "copy this out of the workspace", "get a file from my PC into the workspace", "move a file in/out", "where do my downloads go", or "drag a file into the container". Trigger words: copy file out, copy file in, move file to desktop, get file from desktop, file transfer, /mnt/c, wsl$, \\wsl.localhost, send_files, pull_file, export file, import file, drag into workspace, file to my pc, download to desktop, upload to workspace.
Your Hydrogen Desktop workspace is a PRE-BAKED golden WSL2 image, not a machine that installed itself step-by-step. gallia, the 8 Adom CLIs, the Claude Code VS Code extension, code-server, the VS Code settings / trusted-domains / activity-bar config, AND all the hd-* self- awareness skills are BAKED at image-build time — none of them were installed by a setup step. READ THIS when a user asks "why is X already here", "how do I update gallia", "re-run install-hd-skills / install-gallia / install-claude", or "where did these skills/CLIs come from": the answer is the image, and updates come from a tarball-version bump, NOT a setup step. Trigger words — golden image, pre-baked, baked image, adom-golden, adom-golden.tar.gz, hd-wsl2- image, wsl --import, tarball version, adom-tarball-version, migrate tarball, update gallia, reinstall gallia, install-hd-skills, install-gallia, install- claude-cli, install-claude-ext, verify-adom-desktop, why is gallia here, where did the CLIs come from, how do I update the workspace, re-run setup, lightweight image, install on demand, command not found, ffmpeg not installed, install a tool, apt-get install, missing tool, is ffmpeg installed, install imagemagick/pandoc.
Use when the AI needs to watch the Hydrogen workspace in real-time — react to tab changes, sharing state, user actions, or any workspace mutation as it happens. Covers the SSE event stream, Monitor tool patterns, and example scripts. For point-in-time checks, GET /workspace/health and the control-port GET /workspace/tabs / /workspace/tabs/find are lighter than the proxy SSE. Trigger words: watch workspace, react to tab change, wait until user opens X, workspace event, SSE event, monitor tool, on tab change, real-time react, react to workspace changes, wait for sharing, watch for new panel, workspace_updated, monitor hydrogen, live workspace events.
How Hydrogen Desktop reaches the user OUTSIDE the window — native Windows toast notifications + taskbar 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 orange taskbar flash via request_user_attention(Critical) until the user looks), how toasts route via a PowerShell AUMID so they may show an "Adom" title, and how to fire one with the `notify` desktop command / `adom-desktop notify_user`. Also Pup's browser_alert_window taskbar flash. Windows-only. Trigger words — notify the user, send a notification, desktop notification, toast, windows toast, taskbar flash, get the user's attention, alert the user, notify_user, emergency notification, urgent alert, notification actions, action buttons, ping the user, job done notification, tell me when it's done, flash the taskbar, request attention, browser_alert_window, in-app toast, ui toast, /ui/toast, show a toast in HD, toast inside the window.
The decision guide for "open a URL / open a website" inside Hydrogen Desktop. 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, the Browser Picker chooser, or headless curl/fetch — each with different trade-offs. READ THIS to pick the right one and to explain the options back to the user instead of silently guessing. For the interception/plumbing behind the picker see hd-browser-picker; to drive Pup see pup; for webview tabs see adom-workspace-control. Trigger words — open url, open website, open the site, open ti.com, open a link, pull up the page, show me the website, view this url, open in browser, which browser, how do I open, open the datasheet page, open in a tab, open in pup, open in chrome, headless fetch, ways to open a url, open link options, wv, open in wv, open as wv, webview tab, wv tab, webview, show me in webview, open in webview, in a webview, native webview. NEVER satisfy a webview request with VS Code's built-in Simple Browser — see hd-webview for the exact command.
Master index for all Hydrogen Desktop skills. Start here to find the right skill for any HD topic. Skills are split into a runtime-neutral "shared" set plus a runtime-specific set (WSL2 by default, Docker as legacy fallback). Trigger words: HD skills, hydrogen desktop, what skills, find skill, HD help, HD overview, skill index, HD reference.
Hydrogen Desktop AUTO-GRANTS every WebView2 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 / geolocation: do NOT tell the user to click "Allow" — there is no prompt to click; it's 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 hd-capture- share). Trigger words — permission, permissions, webview2 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, auto-grant, auto granted, why no prompt, permission denied webview.
HD's profile menu — the user-avatar dropdown in the top-right corner that links to your Adom profile/repositories/molecules pages on adom.inc and contains the logout action. Logout is gated by a confirm dialog and returns you to the HD login page; logging in is the gate to using HD at all (no anonymous use). Use when the user asks about "log out", "logout", "sign out", "Your profile", "Your repositories", "Your molecules", the avatar dropdown, the login page, or "why am I locked out". Trigger words — profile menu, avatar menu, top-right avatar, user menu, log out, logout, sign out, confirm logout, login gate, login page, your profile, your repositories, your molecules, adom.inc profile, hd locked out, hd login required, return to login.
PUP — what "pup" means in Hydrogen Desktop and exactly how to open one. When the user says "show me in pup", "open it in pup", "pup window", "in pup", or asks to demo/drive ANY page "in pup", it means a real, AI-drivable Chrome/Edge window opened by Adom Desktop's Puppeteer bridge (auto-installed with HD) on THIS machine — never a webview (see hd-webview), never the user's personal signed-in browser (that's nbrowser). CRITICAL HD DIFFERENCE: in HD, localhost URLs are the NORM for pup (everything binds localhost on the same machine) — the cloud-container rule "pup can't see localhost" is INVERTED here. Trigger words — pup, open in pup, show me in pup, in pup, pup window, puppeteer, pup browser, drive a browser, show the page in pup.
How to record screen + window video from Hydrogen Desktop. In HD the recorder is NATIVE: Windows.Graphics.Capture (per-window, "record kicad") + DXGI full-screen, hardware H.264 (default, universally playable) or H.265 (smaller, not web-playable) → mp4 in ~/project/recordings/, with NO picker, NO "you're sharing" banner, real 30-60fps, and NO display wake-lock. Driven by `adom-cli hydrogen recording start/stop` (which routes to the native control API) or the control endpoints directly (POST /recording/native/start|stop, GET /recording/native/status|sources). A server-side max-duration cap (default 600s) auto-stops + toasts. Read for codec choice, source selection, the cap+reason, and the "● Recording" indicator. Also covers AUDIO-ONLY / narration capture (`adom-cli hydrogen audio` → WebM/Opus in ~/project/audio/), AD host desktop recording (desktop_record_start, Windows-only), the tab-vs-desktop footgun, and what `--mic` does. TWO ENGINES: wgc (GPU, real displays) and gdigrab (ffmpeg GDI — the ONLY engine that records on VMs / virtual / indirect displays / VNC); engine:"auto" probes and falls forward; GET /recording/native/capabilities reports what THIS box supports. Multi-monitor: screen:1..N or screen:all. Trigger words — record, recording, screen recording, record my screen, record kicad, record a window, record whole screen, record the workspace, record a demo, record with mic, record no audio, mic on, mic off, voiceover, record audio, audio-only, record a narration, record my voice, narrate, narration track, record a voice track, h264, h265, hevc, mp4, webm, opus, codec, recordings folder, audio folder, ffmpeg, stitch clips, max duration, recording indicator, desktop_record_start, browser_record_start, start recording, stop and save, record on a vm, virtual display, indirect display, headless recording, vnc recording, 0 frames, zero frames, gdigrab, gdi capture, recording engine, capture engine, record all monitors, record second monitor, multi-monitor recording, recording capabilities, can this machine record.
Which workspace runtime your Hydrogen Desktop is using — a WSL2 Ubuntu distro (default) or a legacy Docker container (HD_RUNTIME=docker) — how to tell which one you're in, what changes between them, and which runtime-specific skills to trust. READ THIS FIRST when anything about the workspace's container/distro, networking, volumes, ports, or setup steps seems contradictory: the answer almost always depends on the runtime. Trigger words — runtime, wsl, wsl2, docker mode, HD_RUNTIME, Adom-Workspace, which runtime, container or distro, workspace runtime, container runtime unhealthy, am I in docker or wsl.
HD screen capture (screenshots + recording) and the display wake-lock. A browser getDisplayMedia capture asserts ES_DISPLAY_REQUIRED, which blocks the user's screensaver and stops the display turning off → burn-in. HD is NATIVE: its screenshots use CDP and its recording uses Windows.Graphics.Capture (WGC) / DXGI — neither holds the display wake-lock — so HD does not have the web leak. HD still must start→capture→release per op, cap recordings, and show a "● recording" indicator so a forgotten recording is never silent. Read before adding or using HD screenshot / screen-recording features. Trigger words: hd screenshot, hd recording, screen capture, wake lock, screensaver blocked, display won't sleep, ES_DISPLAY_REQUIRED, release capture, burn-in, powercfg requests, getDisplayMedia, recording auto-stop, max duration.
Screenshot HD from inside the workspace — a panel/webview (the welcome page, a tab), the whole workspace, OR the whole screen/desktop — using the BUILT-IN `adom-cli hydrogen screenshot`. It saves a PNG into the container's `screenshots/` folder and prints the path to Read. THE answer for "take a screenshot of the welcome page", "screenshot the webview", "screenshot this panel", "screenshot the editor", "screenshot my whole screen / the desktop", "show me what HD looks like", or verifying a UI change (ralph loop). Use this even for "my whole screen / my desktop / my monitor" — that's the `screen` scope, NOT adom-desktop. Do NOT curl host.docker.internal, do NOT use adom-desktop's OS screenshot for anything inside HD (or for the screen), and you do NOT need any image resizer. For a SPECIFIC element/region (a CPU meter, a menu, a dialog, a toolbar) or an inline-b64 PNG, use the canonical `POST /screenshot` control endpoint with a CSS `selector` (it ALWAYS region-clips to that element) — and combine it with the UI command bus (`hd-ui`: `ui/invoke` to open a menu/dialog, then `/screenshot` its selector). Trigger words — screenshot HD, screenshot the welcome page, screenshot the webview, screenshot a panel, screenshot a tab, screenshot the workspace, screenshot the editor, screenshot my screen, screenshot the whole screen, screenshot the desktop, capture my monitor, full screen capture, screenshot everything on screen, what does HD look like, adom-cli hydrogen screenshot, capture panel, capture workspace, capture screen, screenshot a region, clip to selector, screenshot an element, screenshot a menu, screenshot a dialog, region screenshot, b64 screenshot, POST /screenshot, /shot, screenshot without flash, no-flash screenshot, hd_shot, hd_screenshot, screenshot KiCad, screenshot another app, screenshot a non-HD window, desktop_screenshot_window, desktop_screenshot_screen, which screenshot tool, verify visually, ralph loop, shotlog, image resizer, resize screenshot.
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.
Hydrogen Desktop's Settings dialog and the full preference tree the user can change — theme, vim mode, launch-on-boot, console-on-startup, 3D control style, font, line numbers, schematic nudge, the embedded Adom Desktop options, and more. READ THIS when the user asks "how do I turn on vim mode", "change the theme", "make HD launch on boot", "stop Adom Desktop'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, settings dialog, options, config, theme, dark mode, light mode, high contrast, compact ui, developer mode, vim mode, vim emulation, line numbers, code font, editor font, launch on boot, start with windows, show console, console on startup, 3d controls, control style, fusion solidworks blender orbit, schematic nudge, auto approve, foreground hd, adom desktop window, turn on, turn off, change setting, how do I configure.
The catalog of skills available to your Claude inside this Hydrogen Desktop workspace. Lists every public `hd-*` skill that ships with HD and explains what each one is for, so you can pick the right skill before doing anything HD-related. READ THIS FIRST when you're in a fresh HD workspace and want to know what Claude knows. Trigger words — hd skills, what skills do I have, hd catalog, skill index, skill list, what can claude do in hd, hd-* skills, browser picker, hd setup, hd container info, hd networking, hd volume, hd ports.
The maintainer loop for making HD's own hd-* skills perfect: when a skill is wrong, stale, or confusing, verify the truth against the RUNNING HD, fix the skill live in the workspace, then write the corrected file back into the core hydrogen-desktop repo so the next golden-image bake ships it. These skills are the ONLY thing the in-workspace AI knows about HD — a wrong one confuses every Adom user. For Adom devs improving HD. Trigger words — this skill is wrong, stale skill, fix the hd skill, update a skill, the AI got confused by a skill, improve hd skills, skill is inaccurate, debug a skill, skill loop, write skill back to repo, bake skills, golden image skills, skill feedback loop, perfect the skills, skill says X but it actually does Y.
How a Hydrogen Desktop workspace stays current — its Adom tooling (CLIs, skills, apps) updates registry-native via `adom-wiki pkg update` + the `adom/hook` prompt hook, plus the code-server reload banner — and how an Adom employee ships a skill / CLI / app to every workspace. Use when asked "how do I get the latest skills or tooling", "how do updates work here", "what's the reload banner", "how do I distribute a tool to all Adom users", or about the retired workspace-updater daemon (history). Trigger words: staying current, how do updates work, latest skills, get updates, auto update, keep tooling current, distribute a skill, publish to all users, reload banner, adom-wiki pkg update, workspace updater, adom-workspace-updater.
How Hydrogen **webview** tab icons work in the Adom editor — panels with `panelType: adom/a1b2c3d4-0031-4000-a000-000000000031`. (Native panels like Schematic Editor, 3D Editor, Desktop Demo, KiCad panel have their own icon mechanism and are NOT covered here.) The critical gotcha: `displayIcon` (HTTP API) / `--display-icon` (CLI) is only the **pre-load placeholder** — the loaded page's own `<link rel="icon">` overrides it as soon as the page loads. The only stable way to control a webview tab's icon is to serve the favicon you want from your own app. Covers the override mechanism, shipping a custom favicon from a Rust/Node/Python app, using `mdi:<name>` and `data:image/svg+xml;base64,...` placeholders, common icons, and troubleshooting. Trigger words: hydrogen webview tab icon, webview tab icon, mdi icon webview tab, displayIcon webview, display-icon, webview tab icon not showing, custom webview tab icon, colored webview tab icon, tab chip icon, webview tab icon svg, webview tab icon base64, favicon override webview tab, webview tab icon keeps resetting, webview tab icon reverts after page load.
HD's user interface: menus, dialogs, panels, login/logout, profile menu, workspace layout, setup panel — and how to DRIVE them from the workspace via the UI command bus (GET /ui/actions → POST /ui/invoke), the first-class way to open/close/toggle any HD menu or dialog (no CDP clicking). READ when the user asks you to open/close a dialog or menu, operate HD's UI, or you need to know where a UI element is. Trigger words — HD menu, HD dialog, HD panel, open dialog, open menu, close dialog, drive UI, ui/actions, ui/invoke, command bus, ports.open, settings.open, about dialog, profile menu, login, logout, settings, setup panel, Adom menu, HD UI.
WEBVIEW — what the word "webview" means in Hydrogen Desktop and exactly how to open one. When the user says "show me in webview", "open it in webview", "in a webview", "webview panel", "wv", or asks to show ANY app/page/tool "in webview", it ALWAYS means a native Hydrogen workspace webview tab opened via `adom-cli hydrogen webview open-or-refresh` — NEVER VS Code's built-in Simple Browser, never an editor-internal browser, never an iframe hack. Read this the moment the word webview (or wv) appears. Trigger words — webview, wv, show me in webview, open in webview, in a webview, webview tab, webview panel, native webview, show in webview, launch in webview, webview app.
The HD welcome page — shown after setup steps complete. Served from static/welcome.html at http://localhost:1420/welcome.html. Shows Adom branding, "Build and test electronics in the cloud", and an "Open Claude Code" button. This is NOT the adom.inc homepage — it's a local static page bundled with HD. Trigger words: welcome page, welcome tab, show welcome, onboarding page, setup complete page, first launch page.
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.
After editing ANY wiki.adom.inc page (an adom-wiki push/publish, a README/doc/hero change), immediately LOAD that page in pup so the user can see and double-check the rendered result — don't just report the commit hash and move on. Covers how to open the page in pup on the user's machine, refresh it, and post a screenshot to the shotlog for review. Trigger words: wiki update, adom-wiki push, adom-wiki publish, wiki page, show wiki in pup, review wiki, verify wiki page, load wiki page, wiki hero, wiki readme, double-check wiki.
No dev skills in this repo.
How to build, debug, and test this app. Source-only (dev-skills/), never shipped in the tarball.
No publish skills in this repo.
The app-to-wiki publish glue. Source-only (publish-skills/), never shipped in the tarball.
Health: the size chip is green when right-sized, yellow when getting long, red when the model likely skims it. A green check is a passed preamble/structure signal; an amber mark is a gentle nudge, not a hard failure.