Skip to content
cccskills
FreePublished on GitHub

design-system

Review a design system for inconsistent names and hardcoded visual values, document component variants and accessibility behavior, or propose new interface patterns that follow existing rules. Produce structured audits, component references, and design proposals.

OriginalShow the original description

Audit, document, or extend your design system. Use when checking for naming inconsistencies or hardcoded values across components, writing documentation for a component's variants, states, and accessibility notes, or designing a new pattern that fits the existing system.

See how to install

Good for

  • Auditing component names and visual consistency
  • Documenting component variants and states
  • Recording keyboard and screen reader behavior
  • Designing new patterns that fit existing rules

Files included (1)

  • SKILL.md5.5 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

/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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Review a design or web page against WCAG 2.1 AA, an accessibility standard. Organize findings on contrast, keyboard access, forms, and screen reader behavior, with severity levels and practical recommendations for fixes.

  • Review accessibility before design handoff
  • Check text and interface color contrast
  • Review keyboard navigation and focus behavior
anthropics/knowledge-work-plugins30.3KUpdated Oct 17, 2026

account-context

FreeSummary

Build a single brief on an existing customer using available sales records, emails, documents, call notes, and internal chat. Understand the current situation, key contacts, recent discussions, and gaps that may need attention.

  • Preparing for a meeting with an existing customer
  • Catching up on an account during a handover
  • Reviewing recent discussions and stalled opportunities
anthropics/knowledge-work-plugins30.3KUpdated Oct 17, 2026

account-plan

FreeSummary

Build or refresh a strategic customer account plan from sales records, emails, and meeting transcripts. Organize goals, stakeholders, growth opportunities, risks, and dated actions into a document, then sync approved highlights to the customer relationship management system.

  • Creating a quarterly plan for a key customer
  • Refreshing an existing account plan
  • Reviewing stakeholder coverage and growth opportunities
anthropics/knowledge-work-plugins30.3KUpdated Oct 17, 2026

account-research

FreeSummary

Research prospective companies and contacts, check existing customer records, and assess fit against your ideal customer profile. Receive a sourced brief covering recent developments, likely priorities, outreach talking points, and a suggested next step.

  • Researching a company before a sales approach
  • Checking existing account records and ownership
  • Assessing fit against your ideal customer profile
anthropics/knowledge-work-plugins30.3KUpdated Oct 17, 2026

account-research

FreeSummary

Research sales accounts using Common Room data to summarize company details, buying signals, ownership, and key contacts. Answer specific questions directly or prepare a broader briefing with evidence-based next steps, clearly identifying missing information.

  • Prepare a company briefing before a sales conversation
  • Check buying signals and recent account activity
  • Find account owners and key contacts
anthropics/knowledge-work-plugins30.3KUpdated Oct 17, 2026

account-tiering

FreeSummary

Score and group accounts by customer fit and engagement, such as recent contact and open sales opportunities. Identify where to focus sales effort, choose next actions, and spot promising accounts with neglected outreach or missing information.

  • Prioritize a portfolio of assigned accounts
  • Find strong-fit accounts that need outreach
  • Identify promising accounts with no recent activity
anthropics/knowledge-work-plugins30.3KUpdated Oct 17, 2026

See all skills by anthropics

Report a problem with this skill