Build Scalable UI Pattern Libraries

This skill designs and documents UI pattern libraries and design systems, covering component architecture, design tokens, documentation, and governance. It organizes components using atomic design (atoms like buttons and inputs, molecules like search bars and cards, organisms like headers and product lists, then templates and pages) and establishes design tokens as a single source of truth for color (brand and semantic values), spacing, and typography scale. Component APIs are built for consistency - clear prop naming, sensible defaults, and comprehensive variant support.

Use it when building or documenting a design system meant to scale across teams and platforms, not a one-off component for a single feature. It is not a purely visual style guide: it requires quality gates (WCAG 2.1 AA accessibility, cross-browser compatibility, performance benchmarks, visual regression testing, API consistency validation) before a pattern ships.

Given a set of UI needs, it defines essential pattern categories: navigation (primary header and sidebar navigation, secondary tabs and breadcrumbs, numbered or infinite-scroll pagination, progressive disclosure via accordions and expandable cards), input components (variant, size, and state props with a default, filled, or outlined visual system and default, error, success, or disabled states), and feedback patterns (toast, banner, and inline alerts with severity levels, skeleton, spinner, and progress-bar loading states, illustrated empty states with clear CTAs, and graceful-degradation error handling with retry mechanisms). Each component ships with a documentation template covering an overview, usage guidelines (for example, a maximum of one primary button per view, a destructive variant reserved for irreversible actions), a full prop API reference table, live examples, and accessibility notes (a minimum 44px touch target, keyboard focus indicators, screen-reader-friendly labels).

// Comprehensive form input component
const Input = ({ 
  variant = 'default', 
  size = 'md', 
  state = 'default',
  label,
  helpText,
  errorMessage,
  ...props 
}) => {
  const variants = {
    default: 'border-gray-300 focus:border-blue-500',
    filled: 'bg-gray-100 border-transparent',
    outlined: 'border-2 border-gray-300'
  };
  
  const sizes = {
    sm: 'px-3 py-2 text-sm',
    md: 'px-4 py-3 text-base',
    lg: 'px-5 py-4 text-lg'
  };
  
  const states = {
    default: '',
    error: 'border-red-500 focus:border-red-500',
    success: 'border-green-500 focus:border-green-500',
    disabled: 'opacity-50 cursor-not-allowed'
  };
  
  return (
    <div className="input-group">
      {label && <label className="block text-sm font-medium mb-1">{label}</label>}
      <input 
        className={`w-full rounded-md ${variants[variant]} ${sizes[size]} ${states[state]}`}
        {...props}
      />
      {helpText && <p className="text-sm text-gray-600 mt-1">{helpText}</p>}
      {errorMessage && <p className="text-sm text-red-600 mt-1">{errorMessage}</p>}
    </div>
  );
};

Tokens and specs are designed to translate across web, mobile, and desktop and to work with multiple frameworks; version control follows semantic versioning with separate package exports for tokens, components, and styles. Naming conventions favor semantic names over visual descriptions (primary rather than blue), a consistent verb-noun pattern for actions, and clear hierarchy indicators.

Design system teams with defined roles - a design system lead for strategy and governance, component engineers for implementation, design advocates for adoption and training, and community contributors for domain-specific patterns - following a 5-stage contribution workflow (RFC, design review, implementation, beta release, stable release) and maintenance practices like regular component audits, a deprecation strategy, breaking-change communication with migration guides, and usage analytics to guide pattern evolution.