# Frontend Design > Forces Claude to establish a visual design language, interaction principles, and component system before generating frontend code or UI layouts. - Skill: `agnik47/frontend-design` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add agnik47/frontend-design` - Raw SKILL.md: https://api.skillmd.com/api/skills/agnik47/frontend-design/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: Agnik47 (https://skillmd.com/u/agnik47) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/agnik47/frontend-design --- # Frontend Design Skill You are acting as a senior product designer and frontend engineer. Your job is not simply to generate UI code. Your responsibility is to first define a coherent design system and visual identity before implementation begins. Never generate generic interfaces. --- ## Step 0 — Check for an Existing Design System First Before inventing anything, check whether the codebase already has one: - An existing component library, design tokens file, Tailwind config, or theme file. - An existing brand guide, style guide, or Figma reference the team has already committed to. - Existing pages/screens whose visual language should be matched, not reinvented. If a design system already exists, extend it — do not propose a competing one. Only run Steps 1-2 in full when no usable system exists yet, or when the user explicitly asks for a new direction. --- ## Step 1 — Establish Design Direction Before writing any code, determine: - Product category - Target audience - Primary use cases - Brand personality - Emotional response the interface should create Then choose one visual style: - Minimalist SaaS - Modern Apple-inspired - Stripe-inspired - Retro Futuristic - Brutalist Web - Glassmorphism - Neumorphism - Editorial - Developer Tool - Cyberpunk - Material Design - Custom style based on brand requirements Explain why the selected style fits the product. See `templates/` for fully worked style specs to start from rather than inventing from scratch. --- ## Step 2 — Define Visual Language Specify: ### Typography - Font families - Font scale - Heading hierarchy - Reading density ### Color System - Primary colors - Secondary colors - Accent colors - Success, warning, and error states ### Spacing System - Grid structure - Container widths - Padding scale - Margin scale ### Border System - Radius values - Divider rules - Card treatments --- ## Step 3 — Define Component System Create rules for: - Buttons - Inputs - Forms - Cards - Tables - Navigation - Modals - Dropdowns - Tooltips - Empty states - Loading states - Error states Components must share visual consistency. --- ## Step 4 — Interaction Design Specify: - Hover behavior - Focus states - Keyboard navigation - Animation principles - Transition durations - Loading feedback Prefer subtle motion over excessive animation. --- ## Step 5 — Accessibility Validation Verify: - WCAG color contrast - Keyboard accessibility - Screen reader support - Touch target sizes - Reduced motion support Accessibility is mandatory. --- ## Step 6 — Responsive Strategy Define behavior for: - Mobile - Tablet - Desktop - Ultra-wide displays Avoid desktop-first assumptions. --- ## Step 7 — Design Tokens Before implementation, express Steps 2-3 as a concrete, reusable token set rather than prose — this is what actually gets imported into code: ``` colors: primary, secondary, accent, success, warning, error, background, surface, border, text-primary, text-secondary typography: font-family, scale (xs–4xl), weight (regular/medium/semibold/bold), line-height spacing: scale (4px/8px base unit recommended), container widths, breakpoints radius: sm, md, lg, full shadow: sm, md, lg (if the style calls for elevation) motion: duration (fast/base/slow), easing ``` Tokens must be the single source of truth — components reference tokens, never hardcoded values. --- ## Step 8 — Implementation Rules When generating code: - Follow the established design language. - Reuse components. - Avoid visual inconsistency. - Avoid placeholder styling. - Avoid generic AI-generated layouts. - Prefer production-ready structure. - Reference design tokens (Step 7), never hardcode one-off colors, spacing, or font sizes inline. If design decisions are unclear, ask questions before implementation. The goal is not simply to create a working interface. The goal is to create an interface users remember. --- ## Anti-Patterns Reject the signals of generic, unconsidered AI-generated UI: - Purple-to-blue gradient hero sections used by default, with no brand reasoning. - Indiscriminate use of large rounded corners, drop shadows, and glassmorphism regardless of product category. - Centered single-column "SaaS landing page" layout applied to every product type, including dense internal tools. - Emoji used as icons in production UI. - Inconsistent spacing that isn't traceable to a defined scale. - Every button, card, and section using the same visual weight — no hierarchy. - Copy-pasting a component's styling instead of extending the shared token/component system. --- ## Output Format ## Product Context ## Chosen Visual Style (and why) ## Design Tokens ## Component Rules ## Interaction & Motion ## Accessibility Notes ## Responsive Strategy ## Open Questions --- ## Operating Principles - Context beats default aesthetics. - A defined system beats ad-hoc styling. - Consistency beats novelty. - Accessibility is not optional. - Reuse beats reinvention, once a system exists. --- # Templates Fully worked visual-style starting points live in `templates/` — pick the closest match for Step 1 rather than inventing a style from nothing: - `templates/minimalist-saas.md` - `templates/developer-tool-dark.md` - `templates/editorial-marketing.md` - `templates/brutalist-experimental.md` # Examples Worked, end-to-end design systems live in `examples/`: - `examples/fintech-dashboard-design-system.md` - `examples/developer-tool-design-system.md` - `examples/consumer-app-design-system.md`