Create, audit, document, and evolve digital design systems from the bundled universal design-system guide. Use when the user says "create a design system", "write a system brief", "audit our design system", "define tokens", "make a component spec", "plan adoption", "write release notes", "create governance", "build a design-system roadmap", or asks about foundations, color, typography, spacing, motion, media, data visualization, content voice, accessibility, component APIs, component libraries, patterns, templates, themes, modes, multi-brand architecture, platform support, engineering architecture, design tooling, source-of-truth rules, documentation, contribution, deprecation, migration, testing, quality gates, metrics, maturity, templates, or readiness checklists.
Design System
Use this skill to create design systems as durable products: shared language, reusable materials, operating model, and quality standard.
This skill is based on references/universal-guide-*.md, which is the provided universal digital design-system guide split by section range for progressive disclosure. Treat those reference files as canonical. Load the relevant guide sections before making design-system decisions.
Workflow
Identify the requested artifact:
Strategy or alignment: system brief, scope, non-goals, archetype, success measures, audit, principles, quality criteria.
Quality and evolution: testing, quality gates, metrics, team model, maturity, roadmap, failure-mode review, readiness checklist.
Load references/universal-guide-00-introduction-and-toc.md for the table of contents when the task is broad or ambiguous.
Load the smallest set of matching guide references from the routing table below.
Build the requested artifact from the guide's methods and templates.
Validate the output against the relevant readiness checklist, quality model, and common failure modes from the guide.
Guide Routing
references/universal-guide-00-introduction-and-toc.md: guide overview and full table of contents.
references/universal-guide-01-framing-scope-audit-principles.md: sections 1-5; what a design system is, archetypes, boundaries, lifespan, variation model, non-goals, system brief, audit, principles, and quality criteria.
references/universal-guide-02-architecture-operations-foundations-tokens.md: sections 6-9; layer architecture, decision versus delivery layers, shared core and extensions, operating model, foundations, states, and token architecture.
Start by naming the system archetype, boundary, users, non-goals, constraints, expected lifespan, and success outcomes when those affect the decision.
Treat the design system as a product with users, jobs, roadmap, support, release notes, quality targets, adoption metrics, feedback, maintenance cost, and deprecation policy.
Separate language, materials, operations, and evidence. Do not reduce a system to a Figma file, component package, brand PDF, or style guide unless the scope is intentionally that small.
Define stable semantic meaning separately from variable expression. Keep conceptual architecture independent from any single design tool, framework, or platform delivery adapter.
Prefer the smallest effective system. Add components, tokens, variants, and governance only when they solve repeated evidenced problems.
Make contracts explicit: ownership, customization boundaries, accessibility guarantees, supported platforms, source of truth, release process, exception policy, and consumer responsibilities.
Include accessibility, localization, responsive behavior, themes/modes, reduced motion, testing, migration, and quality gates when the artifact can affect shipped UI.
Use the guide's section 34 templates for formal artifacts instead of inventing new formats unless the user requests a different format.
Mark unknowns and assumptions. Do not fill missing organizational facts such as owners, councils, tools, or support channels with invented details.
Final Check
Did the output answer the user's requested artifact, not just summarize the guide?
Did it use the relevant guide section files?
Are principles connected to practical implications, acceptance criteria, and ownership?
Are materials and operations both covered when the system will be maintained?
Are failure modes from section 33 avoided or called out as risks?
Are readiness checklist gaps from section 35 listed as follow-up work?
