
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)
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-systemAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 2.8k |
|---|---|
| repo stars | ★ 23.1k |
| Security audit | 3 / 3 scanners passed |
| Last updated | July 28, 2026 |
| Repository | anthropics/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
/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 patternComponents 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.