Commits a project to ONE named visual style system and applies it consistently at token level. Use when deciding a visual direction for a build — "which style should this be", "pick a visual direction", "style system", "minimalist design", "brutalist site", "soft UI", "clean product UI" — or when a codebase mixes styles and needs to be pulled onto a single coherent system. Contains four complete standalone style specs (minimalist-editorial, brutalist-industrial, soft-depth, product-modern) with palettes, type scales, spacing, shadows, components, and motion. NOT a searchable style/palette database (use ui-ux-pro-max for that), not a workflow command (impeccable), and not creative direction from a brief (taste) — this skill enforces one coherent system end-to-end once a direction is chosen.
Commits a project to ONE named visual style system and applies it consistently at token level. Use when deciding a visual direction for a build — "which style should this be", "pick a visual direction", "style system", "minimalist design", "brutalist site", "soft UI", "clean product UI" — or when a codebase mixes styles and needs to be pulled onto a single coherent system. Contains four complete standalone style specs (minimalist-editorial, brutalist-industrial, soft-depth, product-modern) with palettes, type scales, spacing, shadows, components, and motion. NOT a searchable style/palette database (use ui-ux-pro-max for that), not a workflow command (impeccable), and not creative direction from a brief (taste) — this skill enforces one coherent system end-to-end once a direction is chosen.
Style Systems
One project, one style system. This skill selects a single named visual system and enforces it in every token, component, and animation. Consistency beats novelty: a mediocre system applied perfectly looks better than a great system applied at 80%.
Step 1: Pick the system from the brief
Read the brief (or existing product) and match it against these signals. Pick exactly one. If two systems seem plausible, pick the one matching the AUDIENCE, not the one that looks most impressive.
Once committed, every decision comes from the chosen spec. Violations that count as mixing:
Soft pastel gradients inside a brutalist layout.
A single "fun" rounded card in an otherwise editorial page.
Neumorphic shadows on one component of a flat system.
Borrowing a second system's accent color "just for the CTA".
Switching type personality between marketing pages and app pages of the same product.
If a component feels impossible within the system, the answer is a more disciplined execution of the system — not a borrowed treatment. The only legitimate exception is embedded third-party UI you cannot restyle; isolate it visually rather than adapting your system toward it.
Token-level consistency
Define tokens once, at the top, from the chosen spec. Everything downstream references tokens — never raw values scattered in components.
Colors: define the full palette as CSS custom properties (or Tailwind theme extension). Every color in the app must resolve to a token. If you type a hex value inside a component file, stop and add a token instead.
Type scale: one scale, one or two families, defined once. No per-component font sizes outside the scale.
Spacing: one base unit (the spec says which). All margins/paddings/gaps are multiples of it.
Radius: the spec gives 2–4 radius values. Use only those. Nested radii follow inner = outer − padding.
Shadows: copy the spec's shadow recipes verbatim into tokens (--shadow-sm, --shadow-md, ...). Never improvise a box-shadow inline.
Motion: one duration set + one easing set from the spec, as tokens. All transitions reference them.
Example skeleton (adapt names to the spec):
:root {
/* color */--bg: ...; --surface: ...; --text: ...; --text-muted: ...; --accent: ...; --border: ...;
/* type */--font-display: ...; --font-body: ...; --font-mono: ...;
/* space */--space-1: ...; --space-2: ...; /* multiples of the base unit *//* radius */--radius-sm: ...; --radius-md: ...; --radius-lg: ...;
/* shadow */--shadow-sm: ...; --shadow-md: ...;
/* motion */--duration-fast: ...; --duration-base: ...; --ease-out: ...;
}
Consistency checklist (run before finishing)
Every page and component uses only tokens from the single chosen spec.
Grep for raw hex values / rgb() in component code; each hit is either a token definition or a bug.
Only radius values from the spec appear anywhere.
Only the spec's shadow recipes appear anywhere.
Font families: at most the ones the spec allows, loaded once.
All spacing values are multiples of the spec's base unit.
Motion durations/easings come from the token set.
Each item on the spec's "don't" list is verifiably absent.
Announce which system was applied in your summary to the user.
