Adom UI Design System

@@ -20,7 +20,7 @@ The principles that matter most, in order. Usability and drivability first, poli 6. **Built and driven by the AI.** The AI writes the app, shows it to you, and drives it over a live SSE or WebSocket channel to test and perfect it. Anything the UI can do, a command can do, so state lives on the server and the channel keeps the UI, the CLI, and the AI in lockstep. 7. **One 44px header, three zones,** so people always know which app they are in and where the controls are. 8. **CLIs answer `OK:` or `ERROR:`,** with a `Hint:` that names the exact next command.-9. **Then the polish:** dark `#0d1117` and `#161b22`, one teal accent `#00b8b0`, monochrome-white icons, three fonts by role. On-brand matters, but it comes last.+9. **Then the polish:** dark `#0d1117` and `#161b22`, one teal accent `#00b8b0`, monochrome-white icons, three fonts by role. **Never emoji, never em-dashes** (section 11). On-brand matters, but it comes last. 10. **Lint before you publish.** `adom-ui-linter` turns most of this into deterministic checks.  ---@@ -270,11 +270,11 @@ The `adom-wiki-hero` skill renders this from a template.  ## 11. Copy and voice -The words are part of the experience.+The words are part of the experience, and the first two rules here are absolute, because breaking them makes an Adom app look unprofessional or machine-made. -- **Write for the person, plainly.** Say what a thing does and what will happen, in their language.-- **No em-dashes or en-dashes** in shipped copy. Use commas, colons, periods, parentheses, or "to" for ranges.-- **No gimmick emoji** in product UI text.+- **No emoji. Anywhere.** Not in copy, not on buttons, not in toasts, not in headings, not as icons. Colorful emoji are lame and childlike, and they turn a serious tool into a bowl of Skittles. Adom apps use monochrome line icons (section 9), never emoji. This is a hard rule, not a preference.+- **No em-dashes or en-dashes. Ever.** They are the clearest tell of machine-written text, and an app full of them reads as AI slop, which makes users distrust everything else in the product. Use commas, colons, periods, parentheses, or "to" for ranges (for example, "2 to 3 minutes").+- **Write for the person, plainly.** Say what a thing does and what will happen, in their language, not the system's. - **Name products by their short name,** never with the tagline baked in. - **Lead with the value** the user gets. Tone is professional, for engineers and serious makers. - Provenance over magic: a computed view shows where its data came from and never silently auto-corrects.

@@ -43,7 +43,7 @@ The principles that matter most, in order. Usability and drivability first, poli 6. **Built and driven by the AI.** The AI writes the app, shows it to you, and drives it over a live SSE or WebSocket channel to test and perfect it. Anything the UI can do, a command can do, so state lives on the server and the channel keeps the UI, the CLI, and the AI in lockstep. 7. **One 44px header, three zones,** so people always know which app they are in and where the controls are. 8. **CLIs answer `OK:` or `ERROR:`,** with a `Hint:` that names the exact next command.-9. **Then the polish:** dark `#0d1117` and `#161b22`, one teal accent `#00b8b0`, monochrome-white icons, three fonts by role. On-brand matters, but it comes last.+9. **Then the polish:** dark `#0d1117` and `#161b22`, one teal accent `#00b8b0`, monochrome-white icons, three fonts by role. **Never emoji, never em-dashes** (section 11). On-brand matters, but it comes last. 10. **Lint before you publish.** `adom-ui-linter` turns most of this into deterministic checks.  ---@@ -293,11 +293,11 @@ The `adom-wiki-hero` skill renders this from a template.  ## 11. Copy and voice -The words are part of the experience.+The words are part of the experience, and the first two rules here are absolute, because breaking them makes an Adom app look unprofessional or machine-made. -- **Write for the person, plainly.** Say what a thing does and what will happen, in their language.-- **No em-dashes or en-dashes** in shipped copy. Use commas, colons, periods, parentheses, or "to" for ranges.-- **No gimmick emoji** in product UI text.+- **No emoji. Anywhere.** Not in copy, not on buttons, not in toasts, not in headings, not as icons. Colorful emoji are lame and childlike, and they turn a serious tool into a bowl of Skittles. Adom apps use monochrome line icons (section 9), never emoji. This is a hard rule, not a preference.+- **No em-dashes or en-dashes. Ever.** They are the clearest tell of machine-written text, and an app full of them reads as AI slop, which makes users distrust everything else in the product. Use commas, colons, periods, parentheses, or "to" for ranges (for example, "2 to 3 minutes").+- **Write for the person, plainly.** Say what a thing does and what will happen, in their language, not the system's. - **Name products by their short name,** never with the tagline baked in. - **Lead with the value** the user gets. Tone is professional, for engineers and serious makers. - Provenance over magic: a computed view shows where its data came from and never silently auto-corrects.

@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "1.2.0",+  "version": "1.2.1",   "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": {},