Design, build, or audit professional UI design systems across strategy, product language, foundations, tokens, components, patterns, accessibility, content, Figma/code libraries, documentation, QA, governance, adoption, measurement, theming, releases, and migration. Use when the user wants to create a design-system blueprint, review an existing design system, fix design-system drift, plan Figma/code parity, define token or component architecture, evaluate accessibility and governance maturity, or sequence design-system adoption and migration work.
100
100%
Does it follow best practices?
Impact
100%
1.75xAverage score across 3 eval scenarios
Passed
No known issues
Use this when creating or replacing a professional UI design system from a product, brand, platform, or organization brief.
Collect only inputs that change architecture or risk: product type, audience, platforms, brand/theme model, existing assets, accessibility/compliance needs, team model, maturity target, and delivery expectation.
Use primitive/reference tokens for raw values, semantic/system tokens for intent, component tokens for public component parts or states, and mode/theme tokens for light, dark, high contrast, brand, density, locale, or platform. Primitive tokens should not leak into product UI except inside token definitions.
The blueprint is complete when scope, principles, foundations, tokens, components, patterns, accessibility, content, Figma/code/docs architecture, QA, governance, adoption, measurement, theming, releases, and migration are each specified or explicitly marked out of scope with a reason.