Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
anthropics avatar

Design System

  • 2.8k installs
  • 23.1k repo stars
  • Updated July 28, 2026
  • anthropics/knowledge-work-plugins

design-system is a skill that audits, documents, or extends design systems so teams fix token drift, complete component specs, and add consistent new UI patterns.

About

design-system is an Anthropic knowledge-work plugin skill for managing design systems through audit, document, and extend modes invoked as /design-system audit, document, or extend. It frames design tokens for colors, typography, spacing, borders, shadows, and motion, plus components with variants, states, sizes, behavior, and accessibility, and composite patterns for forms, navigation, data display, and feedback. Principles emphasize consistency over creativity, flexibility within constraints, documenting everything, and versioning with migration paths. Audit output templates score naming consistency, token coverage with hardcoded value counts, component completeness, and priority actions. Document mode produces variant tables, props, states, accessibility notes, do and don't guidance, and code examples. Extend mode captures problem statements, related components, proposed API props, tokens used, and open questions for design review. Optional connector hooks pull Figma component properties when a design tool is connected and publish docs to a knowledge base when available. Tips recommend starting with audit, documenting while building, and prioritizing broad coverage over perfect.

  • Three modes: full audit, per-component documentation, and new pattern extension.
  • Token taxonomy covering colors, typography, spacing, borders, shadows, and motion.
  • Audit templates score naming, hardcoded values, component docs, and priority fixes.
  • Document templates for variants, props, states, accessibility, and do/don't tables.
  • Extend workflow with problem framing, related components, and open design questions.

Design System by the numbers

  • 2,847 all-time installs (skills.sh)
  • +132 installs in the week ending Jul 28, 2026 (Skillselion tracking)
  • Ranked #115 of 1,896 Design & UI/UX skills by installs in the Skillselion catalog
  • Security screen: LOW risk (skills.sh audit)
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
At a glance

design-system capabilities & compatibility

Capabilities
full design system audit scoring · per component variant and state documentation · token coverage and hardcoded value detection tem · new pattern extension proposals · optional figma and knowledge base connector hook
Works with
figma
Use cases
ui design · documentation · frontend
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill design-system

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs2.8k
repo stars23.1k
Security audit3 / 3 scanners passed
Last updatedJuly 28, 2026
Repositoryanthropics/knowledge-work-plugins

Where is our design system inconsistent, undocumented, or missing patterns we need for new UI work?

Audit, document, or extend a design system for naming consistency, token coverage, component completeness, and new pattern proposals.

Who is it for?

Product teams maintaining a shared component library who need systematic audits and documentation templates for variants and accessibility.

Skip if: Skip when you need one-off page mockups without a reusable token or component system to govern.

When should I use this skill?

User runs /design-system audit, document a component, extend a pattern, or asks about naming inconsistencies and hardcoded values.

What you get

Structured audit, component documentation, or new-pattern proposal markdown with scores, tables, accessibility notes, and priority actions.

  • audit report
  • component documentation
  • new pattern specs

Files

SKILL.mdMarkdownGitHub ↗

/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

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

Output — Audit

## Design System Audit

### Summary
**Components reviewed:** [X] | **Issues found:** [X] | **Score:** [X/100]

### Naming Consistency
| Issue | Components | Recommendation |
|-------|------------|----------------|
| [Inconsistent naming] | [List] | [Standard to adopt] |

### Token Coverage
| Category | Defined | Hardcoded Values Found |
|----------|---------|----------------------|
| Colors | [X] | [X] instances of hardcoded hex |
| Spacing | [X] | [X] instances of arbitrary values |
| Typography | [X] | [X] instances of custom fonts/sizes |

### Component Completeness
| Component | States | Variants | Docs | Score |
|-----------|--------|----------|------|-------|
| Button | ✅ | ✅ | ⚠️ | 8/10 |
| Input | ✅ | ⚠️ | ❌ | 5/10 |

### Priority Actions
1. [Most impactful improvement]
2. [Second priority]
3. [Third priority]

Output — Document

## Component: [Name]

### Description
[What this component is and when to use it]

### Variants
| Variant | Use When |
|---------|----------|
| [Primary] | [Main actions] |
| [Secondary] | [Supporting actions] |

### Props / Properties
| Property | Type | Default | Description |
|----------|------|---------|-------------|
| [prop] | [type] | [default] | [description] |

### States
| State | Visual | Behavior |
|-------|--------|----------|
| Default | [description] | — |
| Hover | [description] | [interaction] |
| Active | [description] | [interaction] |
| Disabled | [description] | Non-interactive |
| Loading | [description] | [animation] |

### Accessibility
- **Role**: [ARIA role]
- **Keyboard**: [Tab, Enter, Escape behavior]
- **Screen reader**: [Announced as...]

### Do's and Don'ts
| ✅ Do | ❌ Don't |
|------|---------|
| [Best practice] | [Anti-pattern] |

### Code Example
[Framework-appropriate code snippet]

Output — Extend

## New Component: [Name]

### Problem
[What user need or gap this component addresses]

### Existing Patterns
| Related Component | Similarity | Why It's Not Enough |
|-------------------|-----------|---------------------|
| [Component] | [What's shared] | [What's missing] |

### Proposed Design

#### API / Props
| Property | Type | Default | Description |
|----------|------|---------|-------------|
| [prop] | [type] | [default] | [description] |

#### Variants
| Variant | Use When | Visual |
|---------|----------|--------|
| [Variant] | [Scenario] | [Description] |

#### States
| State | Behavior | Notes |
|-------|----------|-------|
| Default | [Description] | — |
| Hover | [Description] | [Interaction] |
| Disabled | [Description] | Non-interactive |
| Loading | [Description] | [Animation] |

#### Tokens Used
- Colors: [Which tokens]
- Spacing: [Which tokens]
- Typography: [Which tokens]

### Accessibility
- **Role**: [ARIA role]
- **Keyboard**: [Expected interactions]
- **Screen reader**: [Announced as...]

### Open Questions
- [Decision that needs design review]
- [Edge case to resolve]

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

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

Related skills

How it compares

Use design-system for repo-wide UI consistency audits and docs; use single-component refactor skills when only one file needs a quick fix.

FAQ

What are the three design-system modes?

Audit for full system review, document for a single component spec, and extend for proposing a new component or pattern.

What does an audit cover?

Naming consistency, token coverage versus hardcoded values, component completeness scores, and ranked priority actions.

Is design-system safe to install?

Review the Security Audits panel on this page before installing in production.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.