In the Skill's Own Terms
A craft-first discipline for building product UI — dashboards, admin panels, SaaS apps, tools, settings pages, data interfaces — with the decisions a top design team would make. It forces a working brief before code: who the human is, the one verb they came to do, and what the interface should feel like in words that mean something.
From there it prescribes domain exploration (domain, color world, signature, rejected defaults), a type scale built on a ratio with weight and color doing hierarchy work, a single committed depth strategy, semantic tokens rather than hardcoded literals, and the polish and motion essentials — tabular numbers, concentric radius, sub-300ms durations, no animation on high-frequency actions. Explicitly not for landing pages, marketing sites, campaigns or brand-only work.
What it produces
- A Suggest + Ask proposal naming Domain, Color world, Signature, Rejecting and Direction.
- Inline rendered specimens — palette swatches, the type scale in the real typeface, stacked elevation cards, the signature as a real component — when a render tool is present; the implementation itself still lands in the codebase.
- A saved .interface-design/system.md holding direction, depth strategy, hierarchy decisions and repeated component patterns, written only after the user says yes.
How It Works
- 01Write the Working Brief
Before any code, answer who the human is, what verb they must accomplish, and what the interface should feel like — kept compact unless the direction needs confirmation.
- 02Explore the Product Domain
Produce four outputs before proposing a direction: at least 5 domain concepts, 5+ colors from the physical world of the product, one signature element, and 3 obvious defaults to reject.
- 03Propose and Confirm the Direction
Lead with a Suggest + Ask block naming Domain, Color world, Signature, Rejecting and Direction, then check that the direction feels right before building.
- 04Render Specimens Where Possible
If the session has an inline visual-rendering tool, show the palette, type scale, elevation steps and signature as real components instead of describing them; otherwise fall back to code.
- 05Build Against What Exists, Then Verify
Inspect the app, tokens, component patterns and system.md, patch the implementation, run build, typecheck or tests where available, then verify visually at desktop and mobile widths.
- 06Offer to Save the Patterns
After a task, offer to record direction, depth strategy, hierarchy decisions and repeated component patterns so later sessions stay consistent.