| name | frontend-design |
| description | Sets the visual direction for UI work, avoiding generic AI aesthetics. Use for any user-facing UI change: new surfaces, screenshot-driven feedback, copy/density cleanup, settings, control placement, or a "make this look good" pass. Do not load it only for purely mechanical wiring or formatting. |
| scope | dev |
| license | Complete terms in LICENSE.txt |
| source | https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md |
| local-changes | Description deliberately widened on 2026-08-09 because the previous narrow trigger excluded routine UI edits, including screenshot-driven cleanup, copy and density changes, settings, and control placement. An upstream sync must not re-narrow it. Verification remains deliberately rescoped; an upstream sync must not restore screenshot-everything or broad browser-automation steps. |
| metadata | {"internal":true} |
Frontend Design
This skill guides creation of distinctive, production-grade frontend interfaces. Implement real working code with strong product judgment, excellent accessibility, and a clear visual point of view.
The user may ask for a component, page, full app, dashboard, marketing surface, or restyle. Before coding, understand the audience and pick a direction that fits the product instead of defaulting to generic SaaS polish.
Design Thinking
Before coding, decide:
- Purpose: What workflow does this surface make easier? What does the user
need to understand, decide, or do next?
- Audience: Who will use it repeatedly, and what should feel fast, calm, playful, premium, editorial, technical, or utilitarian?
- Tone: Choose a concrete aesthetic direction: refined minimal, dense operations console, editorial, playful, industrial, warm handmade, high-contrast data tool, etc.
- Information hierarchy: What must be visible to orient and act, and what
can wait until context or intent makes it relevant?
- Differentiation: What makes this feel designed for this exact domain?
Then implement working code that is cohesive, accessible, responsive, and polished in small details: typography, spacing, motion, empty states, loading states, focus states, and error states. Polish means removing copy, not writing more of it.
Visual Direction Contract
Before styling a new app or workspace surface, define its product mode,
audience, visual world, palette family, type treatment, composition, shape
language, and anti-references in DESIGN.md. Read
references/visual-direction.md for the direction families and review
vocabulary. This is the Impeccable-inspired design contract for Agent-Native
apps: understand the product, name the mode, deal a few coherent directions,
commit to one, and audit the result instead of averaging back to a starter.
This starter ships no brand system — the neutral, 0%-saturation tokens in
app/global.css are a placeholder, not a design to preserve. Every app must
look impressive on first load even when the build prompt gives no design
direction: commit to one deliberate visual world, set a product-fitting accent
family in the light and dark tokens, and establish a clear type hierarchy,
spacing rhythm, and one signature detail. Do not ship the gray placeholder and
do not average toward generic SaaS. If an app already has a real brand, preserve
it. Keep shared behavior and semantic token names consistent; palette, density,
composition, type contrast, and shape language are yours to define.
Default Surface Density
This is the most repeated correction in this repo, tracked as in
. Every item below has been asked for by
name more than once, usually right after a previous surface was corrected for the
same thing. So treat the list as the default shape you apply, not a tradeoff you
weigh per surface. If the user wants one of these, they will ask.
