skill
Adom UI Design System
Public Made by Adomby adom
How the AI builds and tests interfaces people love to use in Adom. Ships as one installable skill that bundles focused skills (tooltips, floating-windows, toasts, responsive-ui, app-shell, ai-driven-apps, clickable-paths).
← Commit history
Scrub unreleased project name for public page; genericize native-browser surface
2 files changed
+20−22
README.md+2−3@@ -43,7 +43,7 @@ The AI picks the surface by what it needs to test, and it can use more than one | Surface | What it is | Use it for | |---|---|---|-| **Native browser** | The user's real Chrome or Edge, reached through the `adom-browser-extension` | The real, signed-in experience. The browser already holds the user's auth cookies, so the app opens **logged in or auto-logs-in with zero friction**. Huge for demoing and testing anything behind a login. |+| **Native browser** | The user's own Chrome or Edge, driven through Adom Desktop | The real, signed-in experience. The browser is already the user's, so the app opens **logged in with zero friction**. Huge for demoing and testing anything behind a login. | | **pup** | A clean, scriptable Chrome the AI fully owns, via `adom-desktop` | The **fresh, logged-out, first-time-user** experience, and automated screenshot loops that should not fight the user's own tabs. | | **Hydrogen webview** | An in-workspace browser tab | Showing a result inside the workbench, next to the code and the chat. | @@ -313,8 +313,7 @@ This system is split across focused skills. The AI loads them by trigger word. U | `adom-app-header` | The 44px three-zone header and the app-info popover | | `adom-app-model` | How an Adom app is structured, distributed, and versioned | | `adom-screenshot` | Ralph loops and the visual feedback loop for debugging UI |-| `pup-vs-webview` / `adom-desktop-pup` | Choosing and driving pup, webview, or the native browser |-| `adom-browser-extension` | Driving the user's real Chrome or Edge (auth-cookie, auto-login) |+| `pup-vs-webview` / `adom-desktop-pup` | Choosing and driving pup, webview, or the user's native browser | | `adom-cli-design` | The `OK:`/`ERROR:`/`Hint:` CLI contract, in Rust | | `ai-hints-in-clis` | Writing hints that actually steer the AI | | `relay-hint-pattern` | Teaching a relay server to redirect callers to the CLI |
SKILL.md+18−19@@ -3,22 +3,22 @@ name: adom-ui-design user-invocable: true description: >- The Adom UI Design System: how the AI builds AND tests interfaces people love to use in the Adom- ecosystem. The AI writes the app, shows it to the user (in the native browser via the- adom-browser-extension so it is already logged in with the user's auth cookie, in pup for the- logged-out experience, or in a Hydrogen webview), drives the front-end over a live SSE/WebSocket- channel to exercise every path (auto-click buttons, show/hide floaty toolbars, load a different- symbol or footprint, click send-to-kicad), and ralph-loops with screenshots until the UI is- perfect. Covers the user-first interaction rules (instant feedback, controls that explain- themselves, toasts that double as the AI's live narration channel to the user, forgiving errors),- responsive and touch (mobile layouts, tooltips without hover), the 44px app header, AI-drivability- (state on the server, GET /state + /console, the live channel, CLI driving commands), the- OK/ERROR/Hint Rust CLI contract, Babylon 3D viewers, hero rules, and the polish tokens (colors,- fonts, icons) last. Read BEFORE building or testing any Adom UI. Trigger words: ui design, design- system, build an app, build a ui, test the ui, ralph test, ralph loop, drive the front-end,- ai-drivable, ai drivable app, live channel, sse, websocket, server-sent events, show app in- native browser, show app in pup, webview vs pup, auto-click, auto click buttons, toast, ui toast,- app header, 44px header, tooltip, mobile tooltip, responsive, mobile layout, on-brand, color- tokens, theme tokens, cli design, hints, 3d viewer, hero image, ui linter, make my app a joy to use.+ ecosystem. The AI writes the app, shows it to the user (in the user's own already-signed-in native+ browser via Adom Desktop, in pup for the logged-out experience, or in a Hydrogen webview), drives+ the front-end over a live SSE/WebSocket channel to exercise every path (auto-click buttons,+ show/hide floaty toolbars, load a different symbol or footprint, click send-to-kicad), and+ ralph-loops with screenshots until the UI is perfect. Covers the user-first interaction rules+ (instant feedback, controls that explain themselves, toasts that double as the AI's live narration+ channel to the user, forgiving errors), responsive and touch (mobile layouts, tooltips without+ hover), the 44px app header, AI-drivability (state on the server, GET /state + /console, the live+ channel, CLI driving commands), the OK/ERROR/Hint Rust CLI contract, Babylon 3D viewers, hero+ rules, and the polish tokens (colors, fonts, icons) last. Read BEFORE building or testing any Adom+ UI. Trigger words: ui design, design system, build an app, build a ui, test the ui, ralph test,+ ralph loop, drive the front-end, ai-drivable, ai drivable app, live channel, sse, websocket,+ server-sent events, show app in native browser, show app in pup, webview vs pup, auto-click,+ auto click buttons, toast, ui toast, app header, 44px header, tooltip, mobile tooltip, responsive,+ mobile layout, on-brand, color tokens, theme tokens, cli design, hints, 3d viewer, hero image,+ ui linter, make my app a joy to use. --- # Adom UI Design System@@ -66,7 +66,7 @@ The AI picks the surface by what it needs to test, and it can use more than one | Surface | What it is | Use it for | |---|---|---|-| **Native browser** | The user's real Chrome or Edge, reached through the `adom-browser-extension` | The real, signed-in experience. The browser already holds the user's auth cookies, so the app opens **logged in or auto-logs-in with zero friction**. Huge for demoing and testing anything behind a login. |+| **Native browser** | The user's own Chrome or Edge, driven through Adom Desktop | The real, signed-in experience. The browser is already the user's, so the app opens **logged in with zero friction**. Huge for demoing and testing anything behind a login. | | **pup** | A clean, scriptable Chrome the AI fully owns, via `adom-desktop` | The **fresh, logged-out, first-time-user** experience, and automated screenshot loops that should not fight the user's own tabs. | | **Hydrogen webview** | An in-workspace browser tab | Showing a result inside the workbench, next to the code and the chat. | @@ -336,8 +336,7 @@ This system is split across focused skills. The AI loads them by trigger word. U | `adom-app-header` | The 44px three-zone header and the app-info popover | | `adom-app-model` | How an Adom app is structured, distributed, and versioned | | `adom-screenshot` | Ralph loops and the visual feedback loop for debugging UI |-| `pup-vs-webview` / `adom-desktop-pup` | Choosing and driving pup, webview, or the native browser |-| `adom-browser-extension` | Driving the user's real Chrome or Edge (auth-cookie, auto-login) |+| `pup-vs-webview` / `adom-desktop-pup` | Choosing and driving pup, webview, or the user's native browser | | `adom-cli-design` | The `OK:`/`ERROR:`/`Hint:` CLI contract, in Rust | | `ai-hints-in-clis` | Writing hints that actually steer the AI | | `relay-hint-pattern` | Teaching a relay server to redirect callers to the CLI |