What this prompt does
This prompt asks the AI to build a Vue 3 design system component library for [brand_name]. It starts with a design-token system using CSS custom properties for [tokens], builds [component_count] base components ([components]), and adds a theming engine supporting [theme_count] themes with runtime switching. Each component has a clear API — typed props, slots, emits, expose — and is built WCAG [wcag_level] compliant, with responsive behavior via [breakpoint_system].
The structure works because a design system is only worth adopting if it is consistent, accessible, and easy to consume, and this prompt bakes those in from the start. Tokens centralize design decisions so themes are just token swaps; built-in accessibility means components don't fight WCAG later. Storybook documentation, visual regression testing with [vrt_tool], tree-shakeable ESM and CJS exports via Vite library mode, and an npm package with auto-generated types and changelog make it shippable across apps and teams. A clear component API — typed props, slots, emits, and expose — is what determines whether consumers actually adopt the library: components that are easy to compose and extend get used, while opaque ones get worked around, so the prompt treats the public surface of each component as a first-class concern.
When to use it
- You want consistent UI across multiple apps and teams from one shared library.
- You need a token-driven theming engine with
[theme_count]themes and runtime switching. - You want
[component_count]accessible base components built to WCAG[wcag_level]. - You are publishing to npm and need tree-shakeable ESM/CJS with generated TypeScript types.
- You want Storybook docs and visual regression via
[vrt_tool]so changes don't silently break UI. - You want design decisions centralized in
[tokens]rather than scattered across components.
Example output
Expect a token system in CSS custom properties for [tokens], [component_count] typed Vue 3 components ([components]), a theming engine for [theme_count] themes with runtime switching, WCAG [wcag_level] accessibility, [breakpoint_system] responsiveness, Storybook docs with controls and an a11y addon, [vrt_tool] visual regression setup, tree-shakeable ESM/CJS via Vite library mode, and an npm package with auto-generated declarations and changelog.
Pro tips
- Design
[tokens]first and thoroughly — colors, spacing, typography — because every component and theme derives from them, and retrofitting tokens later is painful. - Keep
[theme_count]themes as pure token overrides so runtime switching is a variable swap, not per-component branching. - Build accessibility into each component from the start; bolting WCAG
[wcag_level]compliance on afterward usually means rewrites. - Verify tree-shaking actually works — import one component and check the bundle; barrel files can accidentally pull in the whole library.
- Use
[vrt_tool]snapshots to catch unintended visual changes; without them, a token tweak can silently shift dozens of components. - Match
[breakpoint_system]to your apps' existing breakpoints (e.g. Tailwind-compatible) so consumers don't fight two responsive systems.
