Design System
Audit tokens and components, document variants and a11y, or extend patterns without breaking an existing UI system.
Overview
design-system is an agent skill most often used in Build (also Ship review) that audits, documents, or extends a product’s design tokens, components, and patterns.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill design-systemWhat is this skill?
- 3 modes: audit (full system), document (per component), extend (new pattern)
- Covers 6 token families: color, typography, spacing, borders, shadows, motion
- Component checklist: variants, states, sizes, behavior, and accessibility
- Pattern library framing for forms, navigation, and other composite UI solutions
- 3 modes: audit, document, extend
- 6 design token categories
- 5 component definition dimensions (variants, states, sizes, behavior, accessibility)
Adoption & trust: 2k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your UI kit is growing messy—duplicate token names, undocumented states, and new features that ignore the system you thought you had.
Who is it for?
Indie SaaS or app builders maintaining a component library who want agent-assisted design-system hygiene.
Skip if: Greenfield projects with no components yet where a full audit has nothing to scan, or pure brand-only work with no UI implementation.
When should I use this skill?
When checking naming inconsistencies or hardcoded values, writing component variant and accessibility documentation, or designing a new pattern for the existing system.
What do I get? / Deliverables
You get an audit report, component documentation with a11y notes, or a new pattern spec aligned to existing tokens and components.
- System audit findings
- Per-component documentation
- New pattern specification aligned to tokens
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Design systems are authored and evolved while building product UI; that is the canonical shelf even when audits run pre-release. Frontend is where tokens, components, and patterns are defined and consumed in code and Figma-adjacent workflows.
Where it fits
Document button variants and keyboard focus behavior before agents generate new screens.
Run a full token and naming audit to catch hardcoded hex values before a release branch merges.
Capture token and component rules from a clickable prototype so the production build does not fork the system.
Extend navigation patterns so marketing pages reuse the same header component semantics as the app.
How it compares
Structured design-system playbook instead of one-off “make this button prettier” prompts.
Common Questions / FAQ
Who is design-system for?
Solo builders and small teams shipping web or mobile UI who need audits, living component docs, or new patterns that respect an existing library.
When should I use design-system?
Use it in Build while extending frontend components; in Ship review before launch to audit hardcoded values; and in Validate when documenting a prototype’s UI rules before scaling the codebase.
Is design-system safe to install?
It is documentation- and analysis-oriented; confirm connected tools via CONNECTORS.md and review the Security Audits panel on this Prism page before granting repo or design-tool access.
SKILL.md
READMESKILL.md - Design System
# /design-system > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../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 ```markdown ## 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 ```markdown ## 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 ```markdown ## New Component: [Name] ### Problem [What user need or gap this component addresses] ### Existing Patterns | Related Component | Similarity | Why It's Not Enough | |-------------------|-----------