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-experttools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.