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
1.31.0: viewport report names offenders; a harness matrix is measurement, not verification
2 files changed
+16−2
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-ui-design",- "version": "1.30.0",+ "version": "1.31.0", "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, clickable-paths, dark-default, input-feedback, settings-layout). One install drops the whole set of skill files onto your container, plus shared icon assets (the settings cog) so every Adom app draws the same glyph.", "dependencies": {},
skills/newbie-panel/SKILL.md+15−1@@ -111,7 +111,21 @@ your dashboard a `GET /api/viewport` that reports its OWN `window.innerWidth`, `scrollWidth`, `overflowX` and `devicePixelRatio` back to whoever asks. Then "how wide is the user's pane" stops being an assumption you carry and becomes a fact you-can fetch, and horizontal overflow reports itself instead of waiting to be noticed. It also+can fetch, and horizontal overflow reports itself instead of waiting to be noticed.++**Make it name the OFFENDERS, not just report a number.** kicad's version walks the DOM and+returns which elements exceed the viewport, e.g. `#targetChip:w135,r302` and+`.actions:w100,r410`. That turns "something overflows at 236px" into a culprit list, and it+is how it found that its overflow was in the HEADER (a nowrap brand plus a 135px target chip+plus four ghost buttons) while the panel everyone suspected fitted fine. A symptom sends you+looking; a culprit list sends you fixing.++**A width matrix run in a harness is MEASUREMENT, not verification.** Driving fixed-width+iframes of your own page proves how your CSS cascade behaves and is worth doing across the+whole band. It does not prove anything about the user's surface, so label it as the harness+result it is, and keep the claim "this is what the user sees" for frames captured in their+ah. Preferably run the harness as an in-page iframe INSIDE ah so even the measurement happens+on the real surface. It also gives you an attributable answer: a width you measured through your own page in the user's ah is evidence, where a width you assumed is not.