design-system | SkillBundle

/design-system

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Manage your design system — audit for consistency, document components, or design new patterns.

Usage

/design-system audit                    # Full system audit
/design-system document [component]     # Document a component
/design-system extend [pattern]         # Design a new component or pattern

Components of a Design System

Design Tokens

Atomic values that define the visual language:

Colors (brand, semantic, neutral)
Typography (scale, weights, line heights)
Spacing (scale, component padding)
Borders (radius, width)
Shadows (elevation levels)
Motion (durations, easings)

Components

Reusable UI elements with defined:

Variants (primary, secondary, ghost)
States (default, hover, active, disabled, loading, error)
Sizes (sm, md, lg)
Behavior (interactions, animations)
Accessibility (ARIA, keyboard)

Patterns

Common UI solutions combining components:

Forms (input groups, validation, submission)
Navigation (sidebar, tabs, breadcrumbs)
Data display (tables, cards, lists)
Feedback (toasts, modals, inline messages)

Principles

Consistency over creativity — The system exists so teams don't reinvent the wheel
Flexibility within constraints — Components should be composable, not rigid
Document everything — If it's not documented, it doesn't exist
Version and migrate — Breaking changes need migration paths

Output — Audit

## Design System Audit
 
### Summary
**Components reviewed:** [X] | **Issues found:** [

Output — Document

Output — Extend

If Connectors Available

If ~~design tool is connected:

Audit components directly in Figma — check naming, variants, and token usage
Pull component properties and layer structure for documentation

If ~~knowledge base is connected:

Search for existing component documentation and usage guidelines
Publish updated documentation to your wiki

Tips

Start with an audit — Know where you are before deciding where to go.
Document as you build — It's easier to document a component while designing it.
Prioritize coverage over perfection — 80% of components documented beats 100% of 10 components.

/design-system

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Manage your design system — audit for consistency, document components, or design new patterns.

Usage

/design-system audit                    # Full system audit
/design-system document [component]     # Document a component
/design-system extend [pattern]         # Design a new component or pattern

Components of a Design System

Design Tokens

Atomic values that define the visual language:

Colors (brand, semantic, neutral)
Typography (scale, weights, line heights)
Spacing (scale, component padding)
Borders (radius, width)
Shadows (elevation levels)
Motion (durations, easings)

Components

Reusable UI elements with defined:

Variants (primary, secondary, ghost)
States (default, hover, active, disabled, loading, error)
Sizes (sm, md, lg)
Behavior (interactions, animations)
Accessibility (ARIA, keyboard)

Patterns

Common UI solutions combining components:

Forms (input groups, validation, submission)
Navigation (sidebar, tabs, breadcrumbs)
Data display (tables, cards, lists)
Feedback (toasts, modals, inline messages)

Principles

Consistency over creativity — The system exists so teams don't reinvent the wheel
Flexibility within constraints — Components should be composable, not rigid
Document everything — If it's not documented, it doesn't exist
Version and migrate — Breaking changes need migration paths

Output — Audit

## Design System Audit
 
### Summary
**Components reviewed:** [X] | **Issues found:** [

Output — Document

Output — Extend

If Connectors Available

If ~~design tool is connected:

Audit components directly in Figma — check naming, variants, and token usage
Pull component properties and layer structure for documentation

If ~~knowledge base is connected:

Search for existing component documentation and usage guidelines
Publish updated documentation to your wiki

Tips

Start with an audit — Know where you are before deciding where to go.
Document as you build — It's easier to document a component while designing it.
Prioritize coverage over perfection — 80% of components documented beats 100% of 10 components.