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
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-ui-design",- "version": "1.3.8",+ "version": "1.3.9", "type": "skill", "description": "The Adom UI Design System plus a bundle of focused UI skills (tooltips, floating-windows, toasts, responsive-ui, app-shell, ai-driven-apps). One adompkg install drops the whole set of skill files onto your container.", "dependencies": {},
page.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-ui-design",- "version": "1.3.8",+ "version": "1.3.9", "type": "skill", "description": "The Adom UI Design System plus a bundle of focused UI skills (tooltips, floating-windows, toasts, responsive-ui, app-shell, ai-driven-apps). One adompkg install drops the whole set of skill files onto your container.", "dependencies": {},
skills/ai-driven-apps/SKILL.md+3−3@@ -71,7 +71,7 @@ Pick the surface by what you need to test, and use more than one at once when it | **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**. Use it for anything behind a login. | | **pup** | A clean, scriptable Chrome the AI fully owns | 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. |-| **HD built-in pane** | Under Hydrogen Desktop: a Tauri-managed tab in HD's own pane (HD controls it directly) | Showing a result beside the editor in the desktop app; the `webview` skill routes here when running inside HD. |+| **hdw** (HD Browser Window) | Under Hydrogen Desktop: a standalone Tauri browser window HD manages directly (window label `hd-browse-*`, destination id `webview-window`) | A dedicated app window beside the HD shell — bigger than a pane tab, still HD-managed. Note: the in-HD *pane tab* is the wv surface (the `webview` skill routes there inside HD). | ### VS Code's "Simple Browser" is NOT a surface@@ -85,8 +85,8 @@ instead. When you write or update an app's SKILL.md, include a section titled **"Displaying this app (REQUIRED)"** that (a) names the app's own show/open verb if it has-one, (b) instructs loading the `webview` skill for manual display (pup / native browser / HD's-built-in Tauri pane per the table above), and (c) states the Simple Browser ban verbatim. Skill discovery from+one, (b) instructs loading the `webview` skill for manual display (pup / native browser / hdw per+the table above), and (c) states the Simple Browser ban verbatim. Skill discovery from trigger words alone is probabilistic; the app skill IS reliably loaded when the app is named, so it must carry the display rules itself. (Decision John 2026-07-17, after a fresh workspace showed adom-parts-search in Simple Browser.)