adom/hydrogen-bootstrap

Hydrogen's platform-generic workspace layer, as an adompkg bootstrap. It's a thin package: a dependency list, the bundled hydrogen-* skills, and one config hook. Installing it converges a workspace to "ready to run inside Hydrogen."

adompkg install adom/hydrogen-bootstrap

The golden image runs exactly that line at bake time and ships the result pre-converged. A live workspace can run the same line on demand. The bake is an optimization of the runtime flow, not a different mechanism.

How it layers

adom/hydrogen-bootstrap depends on adom/core and adds only what's specific to running inside Hydrogen. Layering is not a special feature: a layer is just a bootstrap that depends on the one below it. core is pulled unmodified.

adom/core                        ← the Adom ecosystem (shared with Hydrogen Cloud)
  └─ adom/hydrogen-bootstrap     ← THIS: Hydrogen runtime skills + editor config

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 ." See ../BOOTSTRAP-CONVENTION.md for the naming and layering convention.

What's a dependency vs. what's in the hook

The rule: anything that is a package is a dependency; environment config that isn't a package is the postinstall hook; the OS baseline is the golden image's Dockerfile (not this package at all).

Dependencies (all resolve anonymously, sudo-free)

The hydrogen-* skills are bundled into this package (the skills/ dir), not a dependency; they're Hydrogen-specific with no independent lifecycle. Ecosystem CLIs (adom-google, adom-tts, adom-gchat) are inherited via adom/core.

postinstall.sh (deploy bundled skills + environment config)

Runs as the workspace user after all deps install (sudo only for the 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)
2. Claude Code extension (Open VSX) registered in code-server
3. adom-vscode extension .vsix registered in code-server (binary from the core dep)
4. code-server settings.json (dark theme, Claude Code perms, chat/agent panel off, silent ports, no model pin)
5. code-server config.yaml (telemetry + update-check off)
6. workbench.html IndexedDB seed (trusted domains * + activity-bar unpin)
7. tidy (rm ~/project/.mcp.json)

NOT in this package (golden-image Dockerfile)

apt baseline, code-server, systemd/systemd-sysv, cron, the gh CLI, user/group/linger/pam fixes. The "hardware" the bootstrap runs on. A live install assumes a workspace that already has it.

NOT in this package (per-machine, injected by Hydrogen at import)

The Carbon API key, DefaultUid=1001, the host.docker.internal alias.

Notes

• The bundled set is the platform-generic hydrogen-* skills; the Windows-specific ones live in adom/hydrogen-windows-bootstrap, the mac ones in adom/hydrogen-mac-bootstrap. Mixed skills were split: generic core here, a platform companion in the platform layer.
• The generic bundle includes hydrogen-instapcb (and hydrogen-who-am-i's InstaPCB lines): an explicit owner decision (2026-06-19) overriding the general InstaPCB embargo for this package.

Status (2026-08-08)

PUBLISHED + PUBLIC on wiki.adom.inc as part of the 2026-08 naming cutover (formerly adom/hd-bootstrap). Deps resolve anonymously and the whole tree is sudo-free (needs_sudo: false; the retired updater daemon was the only sudo dependency). Build the golden image on the laptop via Adom Bridge or in CI, never in the cloud container.