---
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with a clear visual direction while respecting project design specification constraints, existing design systems, and minimal-diff engineering boundaries. Use when building or restyling pages, landing screens, dashboards, marketing surfaces, or other frontend UI where visual quality materially affects the result.
license: See LICENSE.txt
triggers:
  keywords:
    - "landing page"
    - "hero section"
    - "dashboard"
    - "marketing site"
    - "polish ui"
    - "restyle"
    - "beautify"
    - "redesign"
    - "美化"
    - "重设计"
    - "视觉升级"
    - "设计感"
  negative:
    - "code review"
    - "quality audit"
    - "bugfix"
    - "debug"
---

# Frontend Design

Use this skill to produce frontend work that feels intentionally designed rather than generic. The goal is not maximalism by default. The goal is a clear visual point of view that matches the product context and still ships as maintainable code.

## Trigger

- New frontend surfaces where look and feel matter:
  - landing pages
  - dashboards
  - product pages
  - hero sections
  - marketing sites
  - polished application views
- Requests to beautify, restyle, refine, or modernize an existing UI
- Cases where the code must be working and production-usable, not just a mockup

## Do Not Use

- Pure bug fixes, refactors, or backend tasks
- Review or audit requests
- Small code changes where the user did not ask for visual improvement
- Existing design-system work where the user only wants strict conformance and no meaningful visual interpretation

## Workflow

1. If the request is visually underspecified, ask only the next 1-3 questions needed to clarify audience, tone, and acceptance criteria. Use `requirement-interviewer` when the ambiguity is material.
2. Read `references/design-direction.md` to choose one clear visual direction before coding.
3. Read `references/aesthetics-guidelines.md` for typography, color, motion, composition, and background treatment.
4. Read `references/integration-guardrails.md` before modifying an existing codebase, design system, or shared component surface.
5. For a new page or major redesign, use `assets/templates/visual-brief.md` to form a short visual brief before implementation.
6. Implement working code that matches the chosen direction and stays within project constraints.
7. Read `references/delivery-checks.md` before handing off.

## Output Contract

- State the chosen visual direction in one short sentence when it meaningfully affects implementation.
- Produce working frontend code, not mood-board prose.
- Keep the implementation cohesive:
  - typography should support the direction
  - color should feel intentional
  - motion should be meaningful, not noisy
  - layout should feel composed rather than assembled from defaults
- When editing an existing product, preserve the established system unless the user explicitly wants a stronger redesign.

## Guardrails

- Project design specification constraints, protected files, project stack rules, and user requirements remain hard boundaries.
- Respect the existing design system first. Only deviate when the request explicitly calls for redesign or the current surface clearly lacks a defined visual direction.
- Prefer minimal diffs for scoped tasks. Do not turn a local UI tweak into a whole-app restyle.
- Do not add new dependencies, font loaders, or animation libraries unless the task clearly justifies them.
- Avoid generic AI aesthetics:
  - default-looking font stacks for new standalone surfaces
  - timid palettes
  - predictable card grids with no visual idea
  - purple-gradient-on-white defaults
- Do not optimize for ornament over clarity. If visual flair hurts usability, accessibility, or maintainability, scale it back.