| name | frontend-aesthetics |
| description | Anti-AI-slop taste layer for UI output — distinctive typography, dominant+accent color hierarchy, and implementation-matched polish. Use when building or restyling a UI/landing/component that should look designed rather than defaulted, or when the user asks for something 'beautiful', 'distinctive', 'less generic', or 'not another Tailwind template'. |
| when_to_use | make UI distinctive / beautiful / less generic, typography choice, color hierarchy, restyle a bland component, avoid AI-default look |
| user-invocable | false |
AI-consumed reference. Produce taste; do not re-implement enforcement. This skill complements rules/agent/design-system-usage.md + rules/agent/theme-consistency.md (which enforce token usage) and rules/agent/accessibility-rules.md (which enforces a11y) — cross-link, don't duplicate.
Frontend Aesthetics
Raise output from consistent & correct to distinctive. House-style hard constraint (global CLAUDE.md "12-year-old friendly"): flat, clean, accessible, ONE restrained accent — NO neon, NO glow, NO gradient-mesh, NO sparkle. "Distinctive" = tasteful type + cohesive tokens + dominant color + sharp accent, NOT flashy maximalism. Any output that adds glow/neon fails.
Why this matters (Anthropic, Improving frontend design through skills): generic "AI-look" UI is
distributional convergence — safe choices dominate training data, so sampling drifts to them. A taste
layer + an explicit plan-then-critique step is the documented corrective. This skill is that layer.
Two-pass process (do this BEFORE writing any UI code)
Pass 1 — compact design plan. Write a short plan, not code:
- Color: 4–6 named hex values with role names (derive from ONE hue — see
design-tokens).
- Type: ≥2 type roles (display / body / mono) + the deliberate scale jumps (e.g. 14→20→40).
- Layout: a sentence of intent + a rough ASCII wireframe of the key screen.
- Signature element: the ONE distinctive thing that makes this product not-generic (a specific
treatment of nav / hero / card / empty-state — pick one, commit).
Pass 2 — self-critique the plan against the brief. Before building: if any part of the plan reads
like the generic default you'd produce for any similar page — rather than a choice made for this
brief — revise it, and say what you changed and why. Only then write code.
Persist the result: if .claude/design/design-system.md has no Signature / DoDont, write them
(see rules/agent/design-system-persistence.md).
Typography (the fastest tell of AI-default)
- Avoid the default tells: Inter, Roboto, Open Sans, Arial, raw system-ui.
- Reach for a curated pairing instead: IBM Plex Sans/Serif, Newsreader, Space Grotesk, Bricolage Grotesque, Playfair Display (display only), JetBrains Mono (code/labels).
- Pair with contrast: one expressive display/serif + one clean sans. Make weight & size jumps deliberate and large (e.g. 14 → 20 → 40, not 16 → 18 → 22) — timid scales read as generic.
Color
- Dominant + sharp accent, not an evenly-distributed rainbow: one color owns ~70% of the surface, the accent is used sparingly for the single primary action (ties to the house "1 primary action per screen" rule).
- Derive the palette from ONE hue (see the
design-tokens skill for OKLCH generation) so it reads as a system.
- Accessible-first: verify text/background contrast meets WCAG AA before aesthetics.
Banned AI-default clusters (name them to avoid them)
These are defaults, not choices — they show up regardless of subject. If the plan lands on one by
accident, treat it as a signal to re-pick:
- Warm cream (
#F4F1EA-ish) background + high-contrast serif + terracotta accent.
- Near-black minimal + a single acid-green / electric accent.
- Hairline-rule "broadsheet" — thin gray dividers everywhere as the whole personality.
- The type tells already listed above (Inter / Roboto / Open Sans / raw system-ui).
Any of these is legitimate for a specific brief — but only if chosen for that brief, never as the fallback.
Verify with your eyes (screenshot self-critique)
When the environment can render (dev server / artifact), critique your own work as you build by taking
screenshots — don't ship UI you haven't looked at. For the full render → screenshot → critique → iterate
loop (multi-viewport + dark mode + conformance rubric), hand off to the design-vision-loop skill.
Match ambition to implementation
Only promise polish you'll actually build. A "distinctive" spec with a half-built component reads worse than a restrained one done fully. Ship the smaller, coherent version.
See also: rules/agent/theme-consistency.md, rules/agent/accessibility-rules.md, rules/agent/design-system-persistence.md, the design-tokens skill, and the design-vision-loop skill.
