Design, explore, implement, polish, redesign, and review Epicenter interfaces from product direction through component-system collapse. Use when co-designing a screen, asking "what do other apps do", comparing UI directions or comparable apps, turning a rough feature idea into a buildable Svelte surface, choosing @epicenter/ui components, changing packages/ui, or replacing class-heavy markup and local interface primitives. Not for a tiny CSS-only repair unless it reveals a broader pattern.
79
100%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
ui-design preserves the user-visible objective while reimagining the simplest
greenfield composition and collapsing local markup, arbitrary styling, and
duplicated visual contracts into @epicenter/ui, except where app-specific
behavior or a load-bearing interaction earns the custom shape.
The existing screen is evidence, not a structure to reproduce. For Epicenter
product apps, @epicenter/ui is the default system. Treat shadcn-svelte as
implementation lineage and upstream grounding, not as an app import path.
@epicenter/ui primitives.For substantial work, state the design read:
Objective: <what the user accomplishes>.
Greenfield shape: <the simplest natural component-system composition>.
Collapse: <the local structure or styling that disappears>.Run this for every meaningful UI implementation or review, not only work called a redesign. This is the UI application of asymmetric-wins; load that skill when a candidate refusal needs an explicit product-loss versus deletion-prize decision.
Preserve the product sentence.
Challenge the inherited composition.
Refuse the incidental visual promise.
Delete the local code family.Inspect every wrapper, class bundle, arbitrary Tailwind value, custom color, locally reconstructed state surface, and primitive override. Ask:
Implement obvious collapses directly. Ask the user only when the refusal changes workflow, hierarchy, product meaning, brand posture, or a plausibly load-bearing detail.
Keep custom UI app-local only when it owns app-specific behavior or product
meaning. Move a stable visual contract into packages/ui when several apps need
it or it owns an accessibility or interaction contract.
Ask one focused question when human preference would materially change the visual language, brand posture, primary hierarchy, navigation, density, or the direction of an expressive public surface. Present concrete alternatives and a recommendation. Do not ask about choices settled by the shared system, accessibility, existing product intent, or a mechanical collapse.
Product UI should usually be dense, quiet, and operational. Distinctiveness comes from workflow fit, hierarchy, copy, state design, and purposeful details. Marketing pages, docs entry points, prototypes, and explicitly expressive work can use a stronger visual identity, but still run the collapse pass and keep only details that serve the chosen direction.
packages/ui guide.styling owns CSS, Tailwind, spacing, wrappers, overflow, and scroll traps.svelte owns component structure, runes, lifecycle, and state mechanics.tanstack-table owns table state, columns, sorting, and row identity.web-design-guidelines owns an explicit external standards or accessibility audit.writing-voice owns visible interface copy and tone.The design decision and component-system collapse stay here even when another skill owns their implementation mechanics.
Report the changed surfaces, browser verification, any material deletion prize, and only the custom shapes or pre-flight exceptions that intentionally remain.
cb12bcc
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.