bootstrap
Adom Hydrogen (platform base)
Public Made by Adomby adom
Layer Hydrogen's workspace onto a standard Adom workstation.
← Commit history
Publish 0.2.29
3 files changed
+107−58
package.json+1−1@@ -4,7 +4,7 @@ "type": "bootstrap", "title": "Hydrogen Desktop Bootstrap (apps + skills)", "brief": "Layer Hydrogen Desktop's workspace onto a standard Adom workstation.",- "version": "0.2.28",+ "version": "0.2.29", "description": "Hydrogen Desktop's PLATFORM-GENERIC workspace layer on top of adom/core. Installs adom/core for the full Adom ecosystem, then adds everything common to running inside Hydrogen Desktop on ANY platform: the platform-generic hd-* skills (BUNDLED in this package by design; wsl2 skills ride adom/hd-windows-bootstrap, mac skills ride adom/hd-mac-bootstrap) and the generic HD editor configuration (Claude Code CLI + extension, VS Code settings, trusted domains). Platform-specific layers depend on THIS: adom/hd-windows-bootstrap, adom/hd-mac-bootstrap.", "org": "adom", "tags": [
page.json+1−1@@ -4,7 +4,7 @@ "type": "bootstrap", "title": "Hydrogen Desktop Bootstrap (apps + skills)", "brief": "Layer Hydrogen Desktop's workspace onto a standard Adom workstation.",- "version": "0.2.28",+ "version": "0.2.29", "description": "Hydrogen Desktop's PLATFORM-GENERIC workspace layer on top of adom/core. Installs adom/core for the full Adom ecosystem, then adds everything common to running inside Hydrogen Desktop on ANY platform: the platform-generic hd-* skills (BUNDLED in this package by design; wsl2 skills ride adom/hd-windows-bootstrap, mac skills ride adom/hd-mac-bootstrap) and the generic HD editor configuration (Claude Code CLI + extension, VS Code settings, trusted domains). Platform-specific layers depend on THIS: adom/hd-windows-bootstrap, adom/hd-mac-bootstrap.", "org": "adom", "tags": [
skills/hd-avatar/SKILL.md+105−56@@ -1,81 +1,130 @@ --- name: hd-avatar description: >- Change the user's Adom avatar (profile picture) and make Hydrogen Desktop show the new one- immediately. Use when the user says "change my avatar", "update my profile picture", "set my- avatar to this image", "use this photo as my picture", "reset my avatar", "remove my profile- picture", or hands you an image to use as their avatar. Covers the Carbon upload, the HD- control-API path, and — critically — how to make HD repaint so the old picture isn't left- stale in the title bar and profile menu. Trigger words: avatar, profile picture, profile photo,- change my avatar, update avatar, set avatar, reset avatar, remove avatar, my picture, headshot.+ Generate or change the user's Adom avatar (profile picture), and make Hydrogen Desktop show+ the new one immediately. Use when the user says "generate a new avatar for me", "change my+ avatar", "make me a profile picture", "update my profile photo", "set my avatar to this+ image", "reset my avatar", or hands you an image. The headline flow is GENERATE: research who+ they actually are, propose a design, author it as an SVG, render, upload, and offer to archive+ the vector on a wiki page so future sizes come from a perfect source. Trigger words: avatar,+ generate an avatar, make me an avatar, profile picture, profile photo, change my avatar,+ update avatar, set avatar, reset avatar, remove avatar, my picture, headshot, profile image. --- -# hd-avatar — change the avatar, and make HD show it+# hd-avatar — generate a great avatar, then make HD show it -The avatar appears in HD's title bar and as the header of the profile menu (the **Identity-Card** — see the `identity-card` skill). Two things matter: uploading it, and making the-running HD pick it up.+The avatar appears in HD's title bar and heads the profile menu (the **Identity Card** — see the+`identity-card` skill). The usual request is **"generate a new avatar for me"** with nothing+else: no image file, no brief. That is not a lack of information — it's an invitation to go find+out who they are and design something that actually fits. -## The usual ask: GENERATE one (most people have no image file ready)+**Do not immediately ask "what would you like?"** A blank prompt puts the work back on them.+Research first, then come back with two or three concrete proposals and a reason for each. -"Change my avatar" almost never means "upload this file" — the user rarely has one prepared.-The AI-first answer is to **make the picture for them**, which is fully doable in-container:+## 1. Learn who this person is -1. **Author** the avatar as SVG/HTML — initials on a brand gradient, a mark, whatever they- described. Square, and design it to read at 32px, not just at full size.-2. **Render to PNG** with the Puppeteer-managed Chrome (same pipeline the `adom-wiki-hero-image`- skill uses — the container's `chromium-browser` is a dead stub, and- `chrome --headless --screenshot` hangs; use Puppeteer/CDP with an explicit `browser.close()`):- ```bash- CHROME=$(ls -d /home/adom/.cache/puppeteer/chrome/linux-*/chrome-linux64/chrome | head -1)- # render avatar.html → avatar.png at 512x512- ```-3. **Upload + repaint** (below).-4. **Show them the result** — inject the PNG into shotlog, or just say it's live; never claim- success without checking the hash changed.--Offer a couple of concrete directions rather than asking an open question ("initials on the-brand teal? a minimal circuit mark?") — deciding for them is usually kinder than a blank prompt.--## Change it from a file (when they DO have one)+Start inside Adom, then widen. Take what's cheap and public; stop when you have enough to design+with intent. +**In the Adom ecosystem** (fast, authoritative, no browsing needed): ```bash-adom-cli carbon user avatar-upload /path/to/image.png # any image; 204 on success-adom-cli carbon user avatar-delete # back to the generated default+adom-cli carbon user get # display_name, bio, company, location, website_url+adom-cli carbon user orgs # their organizations (name, display_name, avatar_url)+adom-cli carbon user repos # what they actually build ```+Then their wiki footprint — pages they own, apps/skills they've published, their hero images+(those already encode a visual identity worth echoing): `adom-wiki` discovery, their user page.++**On the wider internet** (only what's public, and only if it adds something):+- Their `website_url` from the profile — usually the highest-signal single source.+- **GitHub** — languages, projects, existing avatar style.+- **LinkedIn** — role, industry, how they present professionally.+- A plain web search on `"<display name>" <company>` for talks, articles, a personal site.+- **Their signed-in browser via adom-desktop** (`nbrowser_*`, the abe extension) can reach a+ Google profile or anything else they're already logged into — see `driving-the-extension`.+ Prefer this over pup for logged-in surfaces.++**Boundaries that matter here.** This is a person, not a target. Use public sources, keep it+proportionate to designing a 512px picture, and **tell them what you found and where** when you+present the concepts. Never put anything you discovered into a public artifact without asking.+If they've said they don't want research, skip straight to asking for a direction.++## 2. Propose, don't guess silently++Come back with **2–3 concepts**, each one sentence, each tied to what you learned:++> - **Monogram** — "JL" in the Adom teal, geometric and quiet. Reads at any size; matches how+> your wiki heroes look.+> - **Craft mark** — a minimal PCB trace forming your initial, nodding to the hardware work in+> your repos.+> - **Portrait abstraction** — flat-color silhouette from your GitHub photo, so you stay+> recognizable across surfaces.++Say which you'd pick and why. Let them redirect before you spend effort rendering.++## 3. Author it as an SVG (and enjoy this part) -## THEN tell HD, or it stays stale+**Vector, always.** SVG is the master: infinitely rescalable, tiny, diffable, and every future+PNG comes from it. -HD caches the signed-in user object at launch. The upload succeeds, but HD keeps painting the-OLD picture until it re-reads the profile. One call fixes that:+Design rules that actually matter for an avatar:+- **Square canvas, centered composition**, safe margin — it gets clipped to a circle everywhere.+- **Legible at 32px.** This is the real constraint. Two shapes and one accent survive; fine+ linework and long text do not. Zoom out and check before you ship.+- **High contrast**, and it must hold on both dark and light chrome.+- Brand teal `#00b8b0` sits naturally in Adom surfaces, but a personal avatar may deliberately+ differ from the platform palette — this is *their* identity, not a UI chrome element.+- No emoji, no clip art, no gradients so subtle they mud at small sizes.++Keep the SVG in their container, e.g. `~/project/avatars/<name>-v1.svg`, so it's editable later.++## 4. Render → upload → repaint ```bash-CTRL="$(cat ~/.adom/hd-control-url)" # HD's live control port-curl -s -X POST "$CTRL/user/refresh" # HD re-reads /user and repaints instantly+# SVG → PNG (512x512). Use the Puppeteer-managed Chrome: the container's chromium-browser is a+# dead stub, and `chrome --headless --screenshot` hangs on real pages. Puppeteer/CDP with an+# explicit browser.close() shoots AND exits (same pipeline as adom-wiki-hero-image).+CHROME=$(ls -d /home/adom/.cache/puppeteer/chrome/linux-*/chrome-linux64/chrome | head -1)++adom-cli carbon user avatar-upload ~/project/avatars/<name>-v1.png # 204 = success+CTRL="$(cat ~/.adom/hd-control-url)"+curl -s -X POST "$CTRL/user/refresh" # HD repaints instantly — otherwise it looks unchanged ``` -Do this **immediately after** any avatar or profile change so the user sees it without-reopening anything. If you skip it, HD still self-heals the next time the profile menu is-opened (it re-reads on open) or on the next HD launch — but the user will notice the lag.--## Why there is no cache-busting to do+**Verify before claiming success:** `adom-cli carbon user get` should show a NEW `avatar_url`+hash. Then show them the result (inject the PNG into shotlog) rather than describing it. -Avatar URLs are **content-hashed** — `https://cdn.adom.inc/avatars/<hash>.png`. A different-image is a different URL, so the CDN can never serve a stale picture and you never need-`?v=` tricks. The ONLY staleness is HD's in-memory user object, which is exactly what-`/user/refresh` clears.+## 5. Offer to archive the vector on the wiki -## The user can also do it themselves+Once they like it, suggest a small personal wiki page holding the **SVG** plus a short note on+the concept. Why it's worth doing:+- The SVG is the perfect-resolution master — future PNGs (any size, a favicon, a talk slide, a+ business card) render from it with no quality loss.+- It survives container resets and moves with them.+- Iterations get a history: `-v1`, `-v2`, and the reasoning behind each. -In HD: click the avatar in the profile menu (a camera badge appears on hover) → pick an image →-HD uploads it and repaints. That path uses the same Carbon endpoint via-`POST <control>/user/avatar` with `{"filename": "...", "data": "<base64>"}`, and-`DELETE <control>/user/avatar` resets to the default.+Ask first — it's their identity and their page. If they'd rather keep it local, the container+copy in step 3 is enough. -## Verify, don't assume+## Change it from a file (when they DO have one) ```bash-adom-cli carbon user get # avatar_url should now show a NEW hash+adom-cli carbon user avatar-upload /path/to/image.png+adom-cli carbon user avatar-delete # back to the generated default ```-Confirm the hash changed before telling the user it worked. If the upload returns non-2xx,-report the status — do not claim success.++## Why HD goes stale, and the one call that fixes it++HD caches the signed-in user at launch, so an upload succeeds while HD keeps painting the OLD+picture. `POST <control>/user/refresh` clears exactly that. HD also self-heals on its own the+next time the profile menu opens (it re-reads then) or on next launch — but the user notices the+lag, so make the call.++There is **no CDN cache to bust**: avatar URLs are content-hashed+(`cdn.adom.inc/avatars/<hash>.png`), so a different image is always a different URL.++## The user can also do it by hand++In HD: profile menu → click the avatar (camera badge on hover), or **Your profile** → *Upload a+photo* / *Remove photo*. Both go through the same Carbon endpoints. The UI is the fallback; the+prompt above is the main event.