frontend-design

Overview of frontend-design skill

What the frontend-design skill is for

The frontend-design skill is a design-first implementation guide for building polished frontend UI that looks intentional rather than AI-generated. It is best for developers, product builders, and AI-assisted coding workflows that need real interface code with stronger visual judgment, not just functional components.

Who should use frontend-design

Use the frontend-design skill if you are:

• building a landing page, app screen, component set, poster, or interactive artifact
• unhappy with generic Tailwind-looking output from ordinary prompts
• able to provide product and brand context before asking for designs
• willing to refine typography, spacing, color, interaction states, and copy instead of accepting the first draft

The real job-to-be-done

What users usually want from frontend-design is not “make it pretty.” They want frontend code that matches a product audience, a brand tone, and a use case well enough to ship or iterate from. The biggest differentiator is that this skill forces context gathering first, then applies concrete design guidance across color, motion, responsiveness, interaction design, typography, spatial design, and UX writing.

What makes this skill different from a generic UI prompt

Compared with a normal “design me a nice UI” request, the frontend-design skill is stricter about:

• requiring target audience, use cases, and brand personality up front
• avoiding default AI aesthetics and overused visual patterns
• designing states, hierarchy, copy, and responsiveness as part of the UI
• using practical frontend details such as :focus-visible, OKLCH colors, content-driven breakpoints, and semantic spacing

Where it fits well and where it does not

This frontend-design skill fits best when you already know the product direction but need stronger execution. It is a weaker fit when:

• you have no audience or brand context yet
• you only need raw wireframes or backend scaffolding
• you want a design system generated without reviewing design tradeoffs
• your priority is strict adherence to an existing company design system rather than creative direction

How to Use frontend-design skill

Install context for frontend-design skill

This skill lives in pbakaus/impeccable at .claude/skills/frontend-design. If your skill runner supports GitHub skill installs, add it from the repository URL your tool expects, then verify the skill is available under the frontend-design slug. The baseline example often used is:

npx skills add https://github.com/pbakaus/impeccable --skill frontend-design

The repository itself does not center on installer tooling, so the important part is confirming your agent can see and invoke the skill files under .claude/skills/frontend-design.

Read these files before first use

For a fast but useful frontend-design guide, read in this order:

1. SKILL.md
2. reference/typography.md
3. reference/color-and-contrast.md
4. reference/spatial-design.md
5. reference/interaction-design.md
6. reference/responsive-design.md
7. reference/motion-design.md
8. reference/ux-writing.md

This order mirrors the biggest quality levers: hierarchy, color, spacing, states, responsiveness, motion, then copy.

The required inputs frontend-design needs

The most important adoption blocker is missing context. The skill explicitly requires at minimum:

• target audience
• use cases
• brand personality or tone

Without those, frontend-design usage becomes guesswork and the output will likely look polished but misaligned.

Strong optional inputs:

• screenshots or references you like and dislike
• existing brand colors, fonts, logo, or voice rules
• the exact surface to design: page, dashboard, checkout, hero, settings panel
• technical stack: React, Vue, plain HTML/CSS, Tailwind, CSS modules
• constraints: accessibility targets, dark mode, mobile-first, design system compatibility

Turn a rough request into a good frontend-design prompt

Weak prompt:

• “Design a modern dashboard.”

Strong prompt:

• “Use the frontend-design skill to create a B2B analytics dashboard for operations managers at mid-size logistics companies. Users check delayed shipments, team workload, and route exceptions several times a day under time pressure. Brand tone should feel calm, competent, and premium rather than playful. Build in React with Tailwind. Prioritize scanability, strong hierarchy, keyboard focus states, and tablet responsiveness. Avoid generic SaaS gradients and card spam.”

The stronger version works because it gives the skill enough material to make design choices instead of defaulting to common templates.

Suggested frontend-design workflow

A practical workflow that matches the repository guidance:

1. confirm design context
2. define the exact screen or component to produce
3. ask for design direction before full implementation if the brief is still loose
4. generate the UI code
5. review against states, hierarchy, copy, responsiveness, and motion
6. iterate on the weakest layer, not the whole screen at once

If you skip step 1, the rest of the workflow loses most of the value of frontend-design for UI Design.

What the skill is opinionated about

The references show clear preferences that materially affect output:

• use OKLCH instead of HSL for more reliable color systems
• tint neutrals subtly toward the brand hue
• design all interactive states, not just hover
• use :focus-visible instead of removing outlines
• prefer content-driven breakpoints and clamp()
• use a 4pt spacing system
• avoid muddy typography scales
• avoid vague button labels like “Submit” or “OK”
• avoid dated motion curves and bouncy effects

These opinions are useful if you want the skill to make design decisions faster; they are a friction point if your team already has conflicting standards.

Practical tips that improve output quality

Ask for these explicitly when using frontend-design:

• a token proposal for color, type, and spacing
• interactive states for buttons, inputs, menus, and destructive actions
• empty, loading, error, and success states
• mobile and coarse-pointer behavior, not just desktop layout
• rationale for any unusual visual direction

This makes the output more reviewable and less likely to hide weak decisions behind polished screenshots or flashy code.

Example prompt structure for frontend-design usage

Use this shape:

• product: what this thing is
• audience: who uses it
• jobs: what they need to get done
• tone: how it should feel
• deliverable: page, component, or flow
• stack: HTML/CSS/JS or framework
• constraints: accessibility, responsiveness, performance, design system
• anti-goals: what to avoid

Example:

• “Use the frontend-design skill to design a patient portal appointment page for older adults managing repeat visits. Tone should feel reassuring, clear, and clinical without looking cold. Build as semantic HTML and CSS. Prioritize large tap targets, visible focus, plain-language labels, and strong empty/error states. Avoid trendy gradients, tiny text, and hidden actions.”

What to inspect in the first output

Do not judge the first draft only by surface polish. Check:

• whether the hierarchy still works when squinting or zooming out
• whether the copy says what actions actually do
• whether focus, disabled, loading, and error states exist
• whether spacing creates structure without overusing cards
• whether typography feels distinctive without hurting readability
• whether hover-dependent interactions still work on touch devices

frontend-design skill FAQ

Is frontend-design good for beginners

Yes, if you can describe your product clearly. The frontend-design skill gives concrete design direction, but it does not replace product decisions. Beginners often get good results when they provide better context than they think they need.

How is frontend-design different from normal prompting

Normal prompts often optimize for speed and visual familiarity. frontend-design pushes the agent to gather context first and then apply stronger UI judgment. In practice, that usually improves originality, state design, typography, and responsiveness more than a one-line prompt does.

Does frontend-design install include code or only guidance

The skill is guidance and reference material for an agent, not a standalone UI component library. The value is in how it steers generation and review. Treat frontend-design install as adding design intelligence to your workflow, not adding ready-made components.

When should I not use frontend-design

Skip it when:

• you need strict reproduction of an existing Figma or company design system
• you only want a quick mock with no product context
• your task is mainly backend, data modeling, or API work
• your team will reject opinionated choices around type, color, or motion

Is frontend-design suitable for production work

Yes, but only with review. The references are production-minded, especially around accessibility, responsiveness, interaction states, and UX writing. Still validate code quality, browser support, and design-system fit before shipping.

Does it work only for websites

No. The repository description covers web components, pages, applications, artifacts, and posters. In practice, it is strongest on frontend surfaces where implementation details and visual design need to meet in the same output.

How to Improve frontend-design skill

Start with better context, not more adjectives

The biggest improvement lever in frontend-design is better product context. “Elegant” or “modern” is less useful than:

• “used on a noisy warehouse floor”
• “targeted at first-time founders”
• “should feel editorial and confident, not corporate”
• “users complete this task in under two minutes on mobile”

This gives the skill reasons for design choices.

Provide references with explanation

Do not just attach screenshots. Say what to borrow and what to avoid:

• “I like the typography contrast here.”
• “I dislike the oversized gradients.”
• “This layout scans well, but feels too enterprise.”
• “Use the restraint of this design, not its exact color palette.”

That helps frontend-design for UI Design stay directional without copying.

Ask for tokens before full screens

If the first outputs feel inconsistent, ask the skill to define:

• color roles
• typography scale
• spacing tokens
• radius and shadow rules
• motion timings
• interaction-state patterns

A small token pass often improves later component generation more than rewriting the whole screen prompt.

Common failure modes to catch early

Watch for these:

• polished visuals with weak audience fit
• hover states without keyboard focus treatment
• attractive colors with poor contrast
• too many card containers instead of clear spacing hierarchy
• generic sans-serif defaults that flatten brand personality
• nice layouts with vague CTA labels
• desktop-first interactions that break on touch

These are exactly the kinds of misses the reference files are trying to prevent.

Improve iteration by targeting one layer at a time

Instead of saying “make it better,” ask for one focused revision:

• “Strengthen visual hierarchy using fewer type sizes and more spacing contrast.”
• “Refine the palette with OKLCH and slightly warm neutrals.”
• “Add the missing interactive states for form controls.”
• “Rewrite all CTAs and validation copy to be specific and outcome-based.”
• “Adjust touch behavior and pointer-specific interactions for tablet use.”

This produces sharper second-pass results.

Use the reference files as review checklists

The reference/ files are not filler; they are best used after generation:

• reference/color-and-contrast.md for palette sanity
• reference/typography.md for hierarchy and measure
• reference/spatial-design.md for spacing and grouping
• reference/interaction-design.md for state completeness
• reference/responsive-design.md for mobile and input method behavior
• reference/motion-design.md for timing and easing
• reference/ux-writing.md for labels, errors, and empty states

If your first output is “close but not shippable,” this is the fastest path to improving it.

How to get better frontend-design results in teams

When multiple people touch the brief, align on three things before invoking frontend-design skill:

• who the primary user is
• what feeling the product should create
• what tradeoffs matter most: speed, trust, delight, density, accessibility

Most weak outputs come from disagreement on those points, not from the skill itself.