Adom Hydrogen (Windows / WSL2)

Windows/WSL2-specific details for Adom auth in HD — the exact %APPDATA% app-data path table for the session/replay/Claude credential files, and how to read the injected Adom API key from outside the WSL2 Adom-Workspace distro. READ alongside the generic [[hd-adom-auth]] skill when you need the concrete Windows file locations or the WSL2 cat command. Trigger words — %APPDATA%, hydrogen-session.txt, replay-session.txt, replay-claude-credentials.json, wsl Adom-Workspace, api-key path, windows auth files, where is the session token on windows.

How to open and drive AI conversations in Hydrogen from your own app, panel, or script: open a new thread (letting the user's preferred AI decide), list what is open, put text in a chat box, send a prompt and confirm it landed, reopen a past conversation, and close a tab. Plain HTTP on Hydrogen's control API, no Tauri IPC and no special privileges. Read this before shelling out to a CLI or driving the editor UI yourself. Trigger words - open an AI thread, new claude thread, new codex thread, new kimi thread, ai threads api, send a prompt to an AI, put text in the chat box, list open AI conversations, reopen a conversation, close an AI tab, default AI, which AI should I use, dock opens a thread, run-prompt job status, background send, where did my prompt go, ai picker toast.

The AI Threads panel in Adom Hydrogen — the live tree of every AI conversation open in the editor (Claude, Codex, Kimi): which is in front, which are busy, drag to reorder, rename, tag, and terminal (TUI) threads that run an AI's full CLI in an editor tab. Covers what the panel shows, the BETA on-startup setting (off by default; nothing AI-Threads runs while it is off), opening it once from Add Panel, TUI threads via the toolbar carets, and how the panel relates to the /ai-threads API (see hydrogen-ai-threads-api for driving it from code). Trigger words: ai threads, ai threads panel, thread tree, my ai conversations, which ai is running, reorder threads, rename a thread, tui thread, claude in a terminal, codex tui, kimi tui, ai threads beta, enable ai threads, ai threads setting.

Windows/WSL2-specific Hydrogen Desktop control-API surface — the /wsl/* runtime endpoints, the legacy /docker/* (HD_RUNTIME=docker) endpoints, /volume-delete, /system/* host-reboot ("Reboot Windows"), the /test/probe-dialogs UAC/MSI/Docker-EULA blocker catalog, WebView2 CDP/DevTools notes, host-side port discovery (HD log + %APPDATA%\hydrogen-desktop\ports.json), and the WSL2 mirrored-networking loopback note. READ alongside the generic [[hd-api]] skill on a Windows host. Trigger words — wsl status, docker status, reboot windows, system reboot, probe-dialogs, UAC dialog, MSI installer, Docker EULA, mirrored networking, ports.json, volume-delete, WebView2, terminal-profile, virgin-reset-progress.

Complete reference for Hydrogen control API endpoints. The control API runs on a dynamic port (find it in the Hydrogen log or via port discovery). Use these endpoints to drive Hydrogen programmatically: manage the workspace (the WSL2 `Adom-Workspace` distro), control Claude Code, manipulate VS Code, manage workspace tabs, run setup steps, trigger virgin reset, and more. 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: Hydrogen API, control API, Hydrogen endpoint, container exec, claude api, iframe eval, workspace tabs, setup run-all, workspace 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 Hydrogen 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 Bridge capabilities. How they connect through adom-bridge, 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.

Hydrogen's Browser Picker — the canonical handler for EVERY URL that gets opened inside Hydrogen. Click a link anywhere (main page, code-server iframe, webview panel, PortMappingsDialog, OAuth redirect, localhost link, external link) and Hydrogen 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, Hydrogen 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 Hydrogen. Trigger words — browser picker, BrowserProfileDialog, hydrogen-open-url, hydrogen-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, hydrogen-links (legacy name).

Windows-specific companion to [[hd-captions]]. The full-DESKTOP overlay caption on Windows — `adom-desktop desktop_caption` — HD's built-in Win32 always-on-top, click-through overlay that floats over ALL windows (above KiCad, Fusion, a browser, the whole screen) and is captured by a full-screen/desktop recording. Covers the desktop-overlay args (text, id, position top/center/bottom/corners, normalized x/y, size/fontSize, duration in MILLISECONDS, action: hide|force-clear) and the id rule (same id replaces, different ids coexist). For the cross-platform WORKSPACE caption (`adom-cli hydrogen caption`, SECONDS units), see [[hd-captions]]. Windows-only. Trigger words — desktop caption, desktop_caption, screen overlay, always on top text, click-through overlay, corner caption, caption id, caption position corners, caption x y, force-clear captions, full-screen caption, caption over other apps, win32 caption overlay.

Paint labeled caption text on the Hydrogen workspace for demos/walkthroughs — captions are CAPTURED BY RECORDINGS so they show up in the finished video. Drive the WORKSPACE caption with `adom-cli hydrogen caption` — THE default, identical on web-Hydrogen AND Hydrogen (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 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]] / [[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 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.

Windows/WSL2-specific mechanism behind HD's title-bar CPU/RAM "Container" indicator — the `workspace_stats()` WSL health/stat probe of the `Adom-Workspace` distro, `wsl --terminate` as the "restart workspace" action, the benign `[docker] unhealthy` log line under WSL, the `[wsl]` real health signal, and WSL distro disk semantics. Companion to [[hd-container-stats]]. Trigger on workspace_stats WSL probe, wsl --terminate, [docker] unhealthy log, [wsl] unhealthy, WslDistroRuntime get_stats, distro disk, restart needed after Windows wake.

Hydrogen's workspace stats indicator in the top-right of the title bar — two thin progress bars (CPU + RAM) labelled "Container" plus an info tooltip on hover that shows the workspace name, CPU vs total cores, RAM usage vs limit, disk usage, image, ID, and creation date. Polls once per second when running, every 5 seconds when stopped. Status badges show stopped / starting / restarting / restart-needed states. Use this skill when the user asks about CPU/RAM usage, the resource bars in Hydrogen's title bar, workspace disk usage, the "restart needed" badge, why bars are red/yellow, or what's in the tooltip. Trigger words — container stats, workspace stats, container cpu, container ram, container disk, resource bars, cpu bar, ram bar, container tooltip, container indicator, top bar stats, restart needed badge, container stopped badge, container starting, workspace_stats, workspace stats.

Windows/WSL2-specific spine for the HD workspace — the `Adom-Workspace` WSL2 distro, how it's imported (`wsl --import` of the golden image), the distro user/exec model, code-server port 7380 auto-forward to Windows localhost, the Rust runtime source, and the Cloud-vs-WSL2 comparison table. Companion to [[hd-container]]. Trigger on Windows host, WSL2, Adom-Workspace distro, wsl --import, wsl exec, distro user, code-server 7380 forward, mirrored networking, golden image distro.

Context for Claude Code running inside a Hydrogen workspace. Documents the exact OS (Ubuntu 24.04, code-server, the local workspace), explains how setup differs from Adom cloud containers (Hydrogen setup-steps NOT bootstrap.sh), what bridges are available, and how to use the relay. Trigger on startup, adom-cli errors, bridge commands, screenshot requests, container-platform questions, code-server / VS Code extension issues, or when the AI needs concrete facts about its environment instead of guessing.

THE recipe for recording a demo video of Hydrogen: 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 Hydrogen feels like. Covers the whole pipeline end to end: driving Hydrogen's control API (in-workspace OR from a remote container via adom-bridge 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, ah demo, demo recording, record the typing, screen record ah, record ai prompt, app demo, demo pipeline, speedup demo, tts overlay demo, show what the app feels like, hydrogen-demo-recording.

Windows/WSL2-specific details for HD's local workspace API + SSE — mirrored-networking loopback sharing, the ports.json location under %APPDATA%, the HD_RUNTIME=docker vs WSL2 relay same-port-vs-host-mapping behavior, and hd-docker create_container env injection. Read alongside the platform-generic [[hd-desktop-sse]]. Trigger words — WSL2 SSE, mirrored networking, ports.json APPDATA, HD_RUNTIME docker, Adom-Workspace distro relay, same-port loopback.

How Hydrogen's local workspace API + SSE works (a.k.a. the workspace API) — replaces Carbon for workspace commands so the workspace's adom-cli controls Hydrogen, not cloud Hydrogen. The workspace is the WSL2 Adom-Workspace distro. Covers the full pipeline, routing, env vars, field format differences, and hard-won lessons. Trigger words — Hydrogen SSE, workspace API, local API, adom-cli workspace, add-tab, move-tab, webview tab, EventSource, workspace_updated, ADOM_CARBON_URL, ADOM_HYDROGEN_URL.

Windows companion to hydrogen-eda-discovery: the ready-to-run probe for detecting EDA tools that have NO bridge (Altium, OrCAD, Cadence/Allegro, EAGLE, DipTrace, Eplan) on a Windows host via install-path scans and process listing through adom-bridge run_script. The generic discovery playbook (branching, the community pitch, etiquette) lives in hydrogen-eda-discovery. Trigger words: detect altium windows, detect orcad windows, program files scan, eda probe windows, no-bridge eda detection, powershell eda probe.

How Hydrogen (ah) and Adom Bridge (ab) interact via "embedded mode". Use whenever the user asks about the system tray icon, why ab isn't visible, why two desktop apps are installed, the "Embedded · Hydrogen" footer pill, or how to make ab show up standalone. Trigger words — embedded mode, system tray, ab tray, why is adom desktop hidden, where's my tray icon, Hydrogen vs ab, both apps installed, why two installs, ab missing from tray, switch ab to standalone, ab won't show, run ab without Hydrogen, decouple ab from Hydrogen.

Move files BOTH WAYS between the Hydrogen 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-bridge relay (send_files / pull_file) relay. 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 workspace starts from a PRE-BAKED golden WSL2 image (v28-full): the tarball already carries the Adom toolchain — adom/core, the Adom CLIs, the hydrogen-* skills and the editor extensions including Claude Code — on top of Ubuntu, systemd, code-server and the folder contract. Setup does NOT install the ecosystem from scratch on a full image; its update-packages step converges what is baked in to the latest published versions. READ THIS when a user asks "where did these skills/CLIs come from", "why did first-run setup take a few minutes", "how do I update the workspace", or "what's actually in the image". Trigger words — golden image, full image, thin image, pre-baked, baked image, adom-golden, adom-golden.tar.gz, wsl --import, tarball version, adom-tarball-version, migrate tarball, install-hydrogen-skills, where did the CLIs come from, how do I update the workspace, re-run setup, install on demand, command not found, missing tool, apt-get install, is ffmpeg installed.

Windows companion to hydrogen-naming: the Windows-specific frozen identifiers and install-surface names for Adom Hydrogen and Adom Bridge. The naming doctrine itself (Formal Names, the installer rule, shorthands, dead names) lives in hydrogen-naming. Trigger words: appdata hydrogen-desktop, installer filename windows, hydrogen exe name, wsl distro name, add remove programs name, autostart registry name.

Port architecture, hostnames, and networking rules for Hydrogen. MUST READ before adding ports, exposing a service to your Windows host, referencing host URLs from inside the workspace, or wiring any service communication. Trigger words — Hydrogen port, Hydrogen network, port mapping, proxy, 127.0.0.1, loopback, mirrored networking, hydrogen-control-url, VSCODE_PROXY_URI, relay URL, code-server proxy, container networking, ADOM_CARBON_URL, ADOM_HYDROGEN_URL, direct connect, 8770, 7380.

Windows-specific companion to [[hd-notifications]]. How HD's native toasts are delivered on Windows — WinRT toasts routed through a PowerShell AUMID (so they may surface under an "Adom" title), and the `emergency` level's persistent ORANGE TASKBAR FLASH via request_user_attention(Critical) that keeps flashing until the user clicks the taskbar icon. Source: notifications.rs. For the cross-platform `notify_user` / `/ui/toast` / Pup-alert API, see [[hd-notifications]]. Windows-only. Trigger words — windows toast, winrt toast, AUMID, Adom title toast, orange taskbar flash, request_user_attention, taskbar attention, emergency notification windows, powershell toast, notifications.rs.

How Hydrogen reaches the user OUTSIDE the window — native OS toast 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 notify_user`. Also the in-app `/ui/toast` (a message INSIDE the Hydrogen window) and Pup's 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 notification, tell me when it's done, request attention, browser_alert_window, in-app toast, ui toast, /ui/toast, show a toast in Hydrogen, toast inside the window, bell icon, notification bell, enable notifications, browser notifications.

The decision guide for "open a URL / open a website" inside Hydrogen. When the user says "open ti.com" / "pull up the datasheet page" / "show me that site", Hydrogen has SIX distinct ways to do it — a Hydrogen webview tab, an Hydrogen 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 hydrogen-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.

Windows-specific companion to [[hd-permissions]]. How HD's webview-permission auto-grant is implemented on Windows: the WebView2 `PermissionRequested` handler that returns `COREWEBVIEW2_PERMISSION_STATE_ALLOW` for every permission kind (mic, camera, clipboard-read, geolocation, notifications, sensors), with lib.rs code evidence. For the cross-platform policy + what it means when building webview apps, see [[hd-permissions]]. Windows-only. Trigger words — webview2 permission, PermissionRequested, COREWEBVIEW2_PERMISSION_STATE_ALLOW, lib.rs permission handler, windows webview auto-grant, webview2 allow, permission auto-grant windows.

Hydrogen AUTO-GRANTS every webview permission — microphone, camera, clipboard-read, geolocation, notifications, sensors — so inside Hydrogen 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 hydrogen-capture-share). Hydrogen's webview engine is platform-specific; the per-engine 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, auto-grant, auto granted, why no prompt, permission denied webview.

Port reachability in Hydrogen — and why you do NOT need to set up port forwarding. Under WSL2 networkingMode=mirrored (Hydrogen's default, which the setup cascade hard-targets), the distro SHARES the Windows loopback, so every port a service binds in the workspace — including `127.0.0.1`-only OAuth callback servers from VS Code extensions (Codex, Copilot, GitLens) — is reachable at the same `localhost:<port>` on Windows automatically. No daemon, no proxies, no manual mapping. The old port-watcher daemon was a Docker/NAT-era mechanism and is not used under mirrored networking. Trigger words: port forward, dynamic port, OAuth callback, Codex auth, extension auth, port mapping, localhost port, port watcher, port proxy, does port forwarding work, why can't I reach my port.

How Hydrogen does port forwarding between your WSL2 workspace and your Windows machine — WSL2's automatic `0.0.0.0` localhost-forwarding (no port map to declare), the code-server `/proxy/<port>/` URL pattern that exposes any internal port, the port-forward registry for `127.0.0.1`-only services that WSL2 won't auto-forward, and the PortMappingsDialog UI. Use when the user asks "why isn't my server reachable", "how do I expose port X", "what's localhost:7380", "register a port", "auto-forward a port", or "the dynamic port dialog". Trigger words — port forwarding, ports, ah ports, container port, proxy port, code-server proxy, /proxy/, port mappings dialog, port hints, auto forward, expose port, register port, host port, dynamic port, ports.json, PortConfig, port resolver, localhost port not working.

How to record screen + window video from Hydrogen. In Hydrogen 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/), ab 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.

Hydrogen 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. Hydrogen is NATIVE: its screenshots use CDP and its recording uses Windows.Graphics.Capture (WGC) / DXGI — neither holds the display wake-lock — so Hydrogen does not have the web leak. Hydrogen 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 Hydrogen screenshot / screen-recording features. Trigger words: ah screenshot, ah 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 Hydrogen 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 Hydrogen 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. 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 (`hydrogen-ui`: `ui/invoke` to open a menu/dialog, then `/screenshot` its selector). Identical across web Hydrogen and Hydrogen. Trigger words — screenshot Hydrogen, 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 Hydrogen 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, which screenshot tool, verify visually, ralph loop, shotlog, image resizer, resize screenshot.

Windows/WSL2-specific details for what HD's setup did — the concrete 16-step `setup_steps_wsl.rs` cascade, the `wsl --import Adom-Workspace` provisioning step, the `wsl --unregister` virgin-reset mechanics, `setup-steps-wsl.json`, and the golden `adom-golden.tar.gz` tarball. READ alongside the generic [[hd-setup-steps]] skill when you need the exact WSL2 steps or file paths. Trigger words — setup_steps_wsl, 16 steps wsl, wsl import, wsl unregister, Adom-Workspace, setup-steps-wsl.json, adom-golden.tar.gz, golden distro, ensure-workspace.

What Hydrogen's setup steps did to prepare your workspace — the install sequence that provisions the golden workspace image, injects your Adom session, wires up the relay, and walks the Claude auth gate. Use this skill when the user asks "what did setup do", "why is X installed", "re-run a setup step", "what's a virgin reset", or "why did step N fail". Trigger words — setup steps, install steps, setup panel, virgin reset, re-run step, Run All, what did setup do, why is X installed, setup failed, install-tools, ah setup, claude code extension install, the Adom CLIs install, ah workspace ready.

Windows/WSL2-specific details for HD setup — the concrete 16-step WSL2 install cascade (setup_steps_wsl.rs), the ensure-workspace `wsl --import` of the golden distro, the `wsl --unregister Adom-Workspace` virgin-reset mechanics, the setup-steps-wsl.json state file, and the never-touch-global-WSL rule. READ alongside the generic [[hd-setup]] skill when you need the exact WSL2 steps, commands, or file paths. Trigger words — 16 steps, setup_steps_wsl, wsl import, wsl unregister, Adom-Workspace, setup-steps-wsl.json, adom-golden.tar.gz, WSL2 cascade, ensure-workspace, virgin reset wsl.

Hydrogen setup panel: the install-step cascade, Run All, Rollback All, Virgin Reset with toggles, and automated testing patterns. MUST READ before running setup, testing steps, or doing virgin resets. Covers the step list, the virgin reset toggle panel, how to keep auth during resets, and how Run All handles failures. Trigger words — setup panel, install steps, run all, virgin reset, rollback, step failed, wipe, reset workspace, keep auth, test setup.

The catalog of skills available to your Claude inside this Hydrogen workspace. Lists every public `hd-*` skill that ships with Hydrogen and explains what each one is for, so you can pick the right skill before doing anything Hydrogen-related. READ THIS FIRST when you're in a fresh Hydrogen 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.

MUST READ before ANY Hydrogen work. Explains the three-layer topology: cloud Docker (where Claude runs), Windows machine (where Hydrogen + Adom Bridge run), and the Hydrogen local WSL2 workspace (the Adom-Workspace distro). Every command you run goes through the relay to Windows. You CANNOT directly access the WSL2 distro — you must shell through Windows. Trigger words — Hydrogen topology, cloud vs local, wsl exec, where am I, which workspace, adom-bridge relay, test from container, three tiers, architecture, windows machine.

Hydrogen'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 Hydrogen menu or dialog (no CDP clicking). READ when the user asks you to open/close a dialog or menu, operate Hydrogen's UI, or you need to know where a UI element is. Trigger words — Hydrogen menu, Hydrogen dialog, Hydrogen 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, Hydrogen UI.

How Hydrogen's WSL2 workspace storage is laid out — what's persistent, what's ephemeral, where your work lives, what survives a workspace restart vs a virgin reset, and how to access your workspace files from your Windows host. Use when the user asks "where are my files", "did I lose my work", "how do I copy a file out of the workspace", or "what happens to my code if I virgin reset". Trigger words — wsl filesystem, hd volume, where are my files, workspace files, persistent storage, lost my work, /home/adom/project, distro filesystem, wsl export, copy file out of workspace, where is my code, workspace backup, wsl unregister.

How Hydrogen automatically repairs the workspace connection after the laptop wakes from sleep: the wake-heal cascade, the header wake indicator with its live info tooltip, the Settings > Desktop > Wake section (heal toggle, indicator toggle, linger slider), and the /wake/* control API endpoints. Read this when the user reports Hydrogen did not reconnect after sleep, sees a "cannot reconnect" dialog, asks what the sunrise/sync icon in the header is, or wants to test or configure wake behavior. Trigger words: wake from sleep, laptop sleep, lid close, sleep resume, resume from sleep, reconnect after sleep, wake repair, wake heal, wake indicator, sunrise icon, cannot reconnect, workspace stuck after wake, wake status, wake simulate, wake settings, run wake check, wake check menu, backend banner, workspace stopped responding, reconnect button.

WSL2 distro (`Adom-Workspace`) lifecycle management for Hydrogen on Windows. Import/export/unregister/terminate, code-server-as-Hydrogen-child, the resume reality-check, recovery after sleep/hibernate, and every hard-won rule about what NOT to do — above all, NEVER run global WSL operations; touch ONLY Adom-Workspace so a co-installed Docker Desktop WSL integration stays safe. MUST READ before any workspace operation. Trigger words — wsl, workspace, distro, Adom-Workspace, restart workspace, terminate distro, unregister, wsl --import, wsl --unregister, code-server, workspace broken, workspace unhealthy, wsl hung, fix workspace, /wsl/status.

Windows/WSL2-specific details for HD workspace monitoring — the "WSL2 Not Available" floaty, the `wsl --terminate Adom-Workspace` stop command, the code-server-on-host-7380 reachability check, and the no-daemon framing (WSL has no always-on daemon to launch). READ alongside the generic [[hd-workspace-monitoring]] skill when you need the concrete WSL2 states, commands, or ports. Trigger words: wsl not available, Adom-Workspace running, wsl terminate, code-server 7380, no daemon, distro stopped, WSL2 floaty.

How Hydrogen monitors and manages the local workspace and code-server. Covers the 15s workspace state poll, the two health levels (runtime available, workspace Running + code-server reachable), the floaty states, auto-start via setup_and_start, auto-reload of the VS Code iframe, and the lifecycle dialog system. Read BEFORE touching PanelVisualStudioCode.svelte, ContainerLifecycleDialog.svelte, or any workspace state handling code. Trigger words: workspace stopped, workspace monitoring, workspace poll, workspace floaty, start workspace, code-server reachable, lifecycle dialog, workspace state, workspace running.

WSLg (Linux GUI apps from the Hydrogen workspace) is OFF by default. How to check it, turn it on or off from inside the workspace through Hydrogen's control API, apply it with a workspace restart, and what to do about the "RemoteApp security warning" dialog. Trigger words - wslg, linux gui app, gui app from wsl, x11, wayland, display not set, cannot open display, guiApplications, turn on wslg, enable gui apps, remoteapp security warning, unknown publisher dummy-entry.