What this prompt does
This prompt designs a production-grade Tailwind CSS component library for the scope you define. You set [library_scope], [framework], [design_tokens], [component_count], [additional_components], and a [css_budget], and it produces a variant system, a list of fully specified components, a theming setup, an accessibility checklist per component, documentation templates, and the Tailwind config additions.
The structure works because a component library lives or dies on consistency, and this prompt enforces it up front. It standardizes on cva or tailwind-variants for variant management, so every component shares the same variant, size, and color axes plus compound variants. Theming runs through CSS custom properties mapped into the Tailwind config rather than scattered dark: classes, and each component carries an ARIA, keyboard, focus, and reduced-motion checklist. The [css_budget] constraint pushes the design toward tree-shakeable, independently importable components.
When to use it
- A client product needs its own design system and you want the variant and theming architecture locked before writing components.
- You're standardizing a sprawl of one-off components into a coherent, reusable library.
- You need consistent dark mode via CSS variables instead of per-element
dark:classes. - You want an accessibility checklist enforced on every component, not bolted on later.
- You're planning to extract the library into an npm package and need tree-shaking and a CSS budget.
- You want Storybook stories and props tables generated alongside each component.
Example output
You get a library blueprint: a variant system built on cva or tailwind-variants with solid/outline/ghost/link variants, xs-through-xl sizes, and semantic colors plus compound variants; full specs for core components (Button, Input, Select, Modal, Toast, Card, Badge) plus your [additional_components]; a theme system with CSS custom properties, a tailwind.config.js extension, and fluid typography; per-component accessibility checklists; documentation and CSF3 Storybook templates; and Tailwind plugin additions with safelist and content paths, targeting your [css_budget].
Pro tips
- Name your real
[framework](React, Vue, Svelte); the component code and variant utility choice depend on it. - Point
[design_tokens]at your actual source (Figma export, JSON) so the theme maps to real brand values. - Use
[additional_components]to extend beyond the core set without losing the shared variant conventions. - Treat
[css_budget]as a real constraint — it pushes the design toward independently importable, tree-shakeable parts. - Generate one component fully first, confirm the variant API feels right, then ask for the rest in the same style.
- Don't strip the per-component accessibility checklist; it's the part most hand-built libraries skip and regret.
