skills/design-system-creator/SKILL.md
Builds comprehensive design systems and design bibles with production-ready CSS. Expert in design tokens, component libraries, CSS architecture. Use for design system creation, token architecture, component documentation, style guide generation. Activate on "design system", "design tokens", "CSS architecture", "component library", "style guide", "design bible". NOT for typography deep-dives (use typography-expert), color theory mathematics (use color-theory-palette-harmony-expert), brand identity strategy (use web-design-expert), or actual UI implementation (use web-design-expert or native-app-designer).
npx skillsauth add curiositech/windags-skills design-system-creatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Design systems architect specializing in comprehensive, scalable design system creation with three-tier token architecture.
If brand token conflicts with semantic token:
├─ Brand name is descriptive (--color-sunset-orange)
│ └─ Keep brand name, map to semantic: --color-primary: var(--color-sunset-orange)
└─ Brand name is generic (--color-primary)
└─ Rename brand to specific: --color-acme-primary, keep semantic --color-primary
If component token conflicts with semantic:
├─ Component is reusable pattern (--button-bg)
│ └─ Keep component token, reference semantic: --button-bg: var(--color-primary)
└─ Component is one-off usage
└─ Use semantic directly: background: var(--color-primary)
If multiple teams contribute tokens:
├─ Core team tokens (spacing, typography)
│ └─ Use unprefixed names: --space-4, --font-size-lg
└─ Feature team tokens (component-specific)
└─ Use team prefix: --commerce-product-card-shadow
If component has < 3 variants:
└─ Document: Purpose, Anatomy, States, Code example
If component has 3-8 variants:
├─ Complex interactions (forms, navigation)
│ └─ Add: Responsive behavior, Accessibility guide, Usage guidelines
└─ Simple variants (buttons, badges)
└─ Add: Variant matrix table, Do/Don't examples
If component has > 8 variants:
└─ Split into sub-components or reconsider if variants are actually needed
If existing codebase:
├─ < 50 components, no naming conflicts
│ └─ Use BEM methodology with component-scoped files
└─ > 50 components OR naming conflicts exist
└─ Use ITCSS structure with strict naming conventions
If greenfield project:
├─ Small team (< 3 developers)
│ └─ ITCSS with utility-first approach
└─ Large team (> 3 developers)
└─ ITCSS with component-scoped methodology
Detection: If you have > 12 spacing tokens or > 20 color tokens per theme Symptom: Developers can't choose between similar options Fix: Consolidate to max 8 spacing values, use semantic layer to reduce primitive exposure
Detection: Components directly reference primitive tokens (--color-blue-500) Symptom: Theming breaks, can't swap brands without touching every component Fix: Audit all CSS, replace primitives with semantic tokens, add linting rules
Detection: Design bible shows different values than actual CSS implementation Symptom: Developers stop trusting documentation, inconsistencies multiply Fix: Generate documentation from CSS comments or implement single source of truth
Detection: HTML classes exceed 5-6 utility classes per element Symptom: HTML becomes unreadable, design intent is lost in implementation Fix: Create component classes for common patterns, limit utilities to tweaks
Detection: Custom values appear outside the design token system (padding: 13px) Symptom: Visual inconsistency, system erosion over time Fix: If scale doesn't work, fix the scale—don't work around it
Scenario: E-commerce platform needs to support 3 brands with shared components but different visual identity.
Initial Assessment:
Decision Process:
Token Architecture Decision: Need three-tier system
Migration Strategy Decision:
Implementation:
/* Brand A Theme */
:root[data-brand="acme"] {
--color-primary: var(--acme-red-500);
--color-secondary: var(--acme-gray-600);
}
/* Brand B Theme */
:root[data-brand="beta"] {
--color-primary: var(--beta-blue-600);
--color-secondary: var(--beta-slate-600);
}
/* Components use semantic tokens */
.button--primary {
background: var(--color-primary);
color: var(--color-on-primary);
}
Validation: Built 3 key pages in all brands, caught 12 contrast issues early
Expert Insight: Novice would try to solve with CSS-in-JS theming. Expert recognizes CSS custom properties provide better performance and simpler mental model.
Result: 6-week delivery met, 95% code reuse across brands, 0 critical bugs in production.
Do NOT use this skill for:
typography-expert for font choices, reading hierarchycolor-theory-palette-harmony-expert for color relationshipsweb-design-expert for logo, brand colors, visual personalityweb-design-expert for React/Vue or native-app-designer for mobileweb-design-expert for custom iconographynative-app-designer for interaction designDelegation triggers:
color-theory-palette-harmony-expertnative-app-designertypography-expertweb-design-expertdata-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.