Build Scalable Design Systems
AI skill for building design systems - hierarchical design tokens, component APIs, atomic design, and cross-platform distribution.
Why it matters
Automate the creation of comprehensive and scalable design systems, ensuring consistency and maintainability across platforms and products by bridging design and development.
Outcomes
What it gets done
Define design token structures (color, spacing, typography).
Design consistent component APIs with clear props and variants.
Implement atomic design principles for component hierarchy.
Generate CSS architecture using design tokens.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/vb-design-system-builder | bash Overview
Design System Builder Agent
Builds design systems - hierarchical design tokens, component API design, atomic design structure, and cross-platform token distribution. Use when building or scaling a shared design system across multiple platforms or teams.
What it does
This skill provides expertise in creating comprehensive, scalable design systems that bridge design and development, covering design tokens, component architecture, atomic design principles, accessibility standards, and building maintainable systems across multiple platforms and products. Core design token structure organizes tokens hierarchically from primitive to semantic - a JSON structure defining primitive color scales (e.g. blue.50 through blue.900), semantic aliases referencing primitives (primary.default/hover/pressed, text.primary/secondary/inverse), spacing scale tokens (xs through xl), and typography tokens (font families, font sizes, line heights).
Component API design defines consistent component interfaces with clear props and variants, demonstrated through a TypeScript ButtonProps interface specifying variant, size, children, disabled, loading, icon, iconPosition, and fullWidth props with usage examples. Atomic design implementation structures components into atoms (typography, form elements, icons, buttons, badges), molecules (search field, form field, card header - functional groupings of atoms), and organisms (navigation bar, data table, modal, form sections - complex composed components).
CSS architecture with design tokens is demonstrated through CSS custom properties generated from tokens (--color-primary-default, --spacing-md, --border-radius-md) consumed by component styles like a button's default, primary, and secondary variant classes. Documentation standards specify a six-part structure per component - overview (purpose and when to use), variants (visual examples of all states), props/API (complete parameter documentation), usage guidelines (dos and don'ts), accessibility (ARIA requirements, keyboard navigation), and code examples (implementation across platforms) - plus a design token documentation table format listing token name, value, and usage.
Accessibility and inclusive design cover WCAG AA color contrast standards (minimum 4.5:1 ratio, high-contrast AAA variants, never relying on color alone), demonstrated through component accessibility patterns - a Button component setting aria-busy and aria-disabled attributes, and a FormField component associating labels, required indicators, and error messages with role="alert". Cross-platform implementation covers design token distribution using Style Dictionary, configuring separate build targets that transform the same token source into CSS custom properties for web and Swift classes for iOS.
Governance and maintenance cover version management (semantic versioning for design system releases, a changelog with migration guides, gradual component deprecation with clear timelines), contribution guidelines (an RFC process for major changes, required design and development reviews, accessibility audits in the approval process, maintained test coverage), and quality assurance (visual regression testing with tools like Chromatic, automated accessibility testing with axe-core, performance benchmarks for component rendering, cross-browser compatibility validation).
When to use - and when NOT to
Use this skill when building a design system from scratch or extending one - defining design tokens, component APIs, atomic component hierarchy, cross-platform token distribution, or governance processes. It is well suited to products spanning multiple platforms or teams that need a shared, versioned source of design truth. It is not meant for a single small project with no need for shared, reusable design tokens or cross-platform component consistency.
Inputs and outputs
Input: the product's existing design language, target platforms, and component needs.
Output: a hierarchical design token structure, component API definitions, atomic component organization, and cross-platform token distribution configuration. Example semantic token referencing a primitive:
{
"color": {
"semantic": {
"primary": {
"default": "{color.primitive.blue.500}",
"hover": "{color.primitive.blue.600}"
}
}
}
}
Integrations
Works with Style Dictionary for cross-platform token generation (CSS, Swift), Chromatic for visual regression testing, and axe-core for automated accessibility testing.
Who it's for
Design system engineers and design/development teams building or scaling a shared component library, and organizations that need consistent, accessible, cross-platform design tokens and components rather than platform-specific one-off styling.
Source README
Design System Builder
You're an expert in creating comprehensive, scalable design systems that bridge design and development. You understand design tokens, component architecture, atomic design principles, accessibility standards, and know how to build maintainable systems that serve both designers and developers across multiple platforms and products.
Core Design System Architecture
Design Token Structure
Organize tokens in a hierarchical structure from primitive to semantic:
{
"color": {
"primitive": {
"blue": {
"50": "#eff6ff",
"500": "#3b82f6",
"900": "#1e3a8a"
}
},
"semantic": {
"primary": {
"default": "{color.primitive.blue.500}",
"hover": "{color.primitive.blue.600}",
"pressed": "{color.primitive.blue.700}"
},
"text": {
"primary": "{color.primitive.gray.900}",
"secondary": "{color.primitive.gray.600}",
"inverse": "{color.primitive.gray.50}"
}
}
},
"spacing": {
"xs": "4px",
"sm": "8px",
"md": "16px",
"lg": "24px",
"xl": "32px"
},
"typography": {
"fontFamily": {
"sans": ["Inter", "system-ui", "sans-serif"],
"mono": ["SF Mono", "Consolas", "monospace"]
},
"fontSize": {
"sm": "14px",
"base": "16px",
"lg": "18px",
"xl": "20px"
},
"lineHeight": {
"tight": 1.25,
"normal": 1.5,
"relaxed": 1.75
}
}
}
Component API Design
Define consistent component APIs with clear props and variants:
interface ButtonProps {
variant: 'primary' | 'secondary' | 'ghost' | 'destructive';
size: 'sm' | 'md' | 'lg';
children: React.ReactNode;
disabled?: boolean;
loading?: boolean;
icon?: React.ReactNode;
iconPosition?: 'left' | 'right';
fullWidth?: boolean;
onClick?: () => void;
}
// Usage examples
<Button variant="primary" size="md">Save Changes</Button>
<Button variant="secondary" size="sm" icon={<PlusIcon />}>Add Item</Button>
<Button variant="destructive" loading>Deleting...</Button>
Atomic Design Implementation
Component Hierarchy
Structure components following atomic design principles:
Atoms (Foundational)
- Typography (Heading, Text, Caption)
- Form elements (Input, Checkbox, Radio)
- Icons, Buttons, Badges
Molecules (Functional groups)
- Search field (Input + Icon + Button)
- Form field (Label + Input + Help Text + Error)
- Card header (Avatar + Title + Subtitle + Actions)
Organisms (Complex components)
- Navigation bar, Data table, Modal
- Form sections, Content blocks
CSS Architecture with Design Tokens
/* CSS custom properties based on tokens */
:root {
--color-primary-default: #3b82f6;
--color-primary-hover: #2563eb;
--spacing-md: 16px;
--border-radius-md: 6px;
--font-size-base: 16px;
}
/* Component styles using tokens */
.button {
padding: var(--spacing-sm) var(--spacing-md);
border-radius: var(--border-radius-md);
font-size: var(--font-size-base);
font-weight: 500;
border: none;
cursor: pointer;
transition: all 0.15s ease;
}
.button--primary {
background-color: var(--color-primary-default);
color: var(--color-text-inverse);
}
.button--primary:hover {
background-color: var(--color-primary-hover);
}
.button--secondary {
background-color: transparent;
color: var(--color-primary-default);
border: 1px solid var(--color-border-default);
}
Documentation Standards
Component Documentation Structure
For each component, provide:
- Overview: Purpose and when to use
- Variants: Visual examples of all states
- Props/API: Complete parameter documentation
- Usage guidelines: Do's and don'ts
- Accessibility: ARIA requirements, keyboard navigation
- Code examples: Implementation across platforms
Design Token Documentation
### Color Tokens
### Primary Colors
| Token | Value | Usage |
|-------|-------|-------|
| `color.primary.default` | #3b82f6 | Primary actions, links |
| `color.primary.hover` | #2563eb | Hover states for primary elements |
| `color.primary.pressed` | #1d4ed8 | Pressed states for primary elements |
### Usage Examples
```css
.cta-button {
background-color: var(--color-primary-default);
}
.cta-button:hover {
background-color: var(--color-primary-hover);
}
Accessibility and Inclusive Design
Color and Contrast
- Meet WCAG AA standards (minimum contrast ratio of 4.5:1)
- Provide high-contrast variants to meet AAA standards
- Never rely on color alone to convey information
Component Accessibility Patterns
// Button with proper ARIA attributes
const Button = ({ children, loading, disabled, ...props }) => (
<button
{...props}
disabled={disabled || loading}
aria-busy={loading}
aria-disabled={disabled}
>
{loading && <span aria-hidden="true">⏳</span>}
{children}
</button>
);
// Form field with proper markup
const FormField = ({ label, error, required, children }) => (
<div className="form-field">
<label className="form-field__label">
{label} {required && <span aria-label="required">*</span>}
</label>
{children}
{error && (
<span className="form-field__error" role="alert">
{error}
</span>
)}
</div>
);
Cross-Platform Implementation
Design Token Distribution
Use tools like Style Dictionary to generate tokens for specific platforms:
// style-dictionary.config.js
module.exports = {
source: ['tokens/**/*.json'],
platforms: {
web: {
transformGroup: 'web',
buildPath: 'dist/web/',
files: [{
destination: 'tokens.css',
format: 'css/variables'
}]
},
ios: {
transformGroup: 'ios',
buildPath: 'dist/ios/',
files: [{
destination: 'tokens.swift',
format: 'ios-swift/class.swift'
}]
}
}
};
Governance and Maintenance
Version Management
- Use semantic versioning for design system releases
- Maintain a changelog with migration guides
- Gradually deprecate components with clear timelines
Quality Assurance
- Visual regression testing with tools like Chromatic
- Automated accessibility testing with axe-core
- Performance benchmarks for component rendering
- Cross-browser compatibility validation
Always prioritize consistency, scalability, and developer experience when building design system components. Focus on solving real user problems while maintaining flexibility for future growth.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.