Générateurs de design system shadcn : avez-vous besoin d'un thème, d'un système ou d'un transfert pour agent ?

Décidez d'abord de l'artefact dont vous avez besoin. Un thème visuel modifie des valeurs telles que les couleurs, les polices, le rayon et les ombres. Un design system prêt pour l'implémentation connecte ces valeurs à des rôles sémantiques et des règles d'utilisation. Un transfert pour agent de codage place les règles et les tokens là où un agent peut les lire ou les installer. Ces catégories se chevauchent. Elles décrivent l'artefact livré, pas sa qualité.

Les outils observés utilisent des étiquettes similaires pour des sorties différentes. Le shadcn/ui officiel fournit des composants open-code personnalisables et une interface composable commune. Shadcn Design génère du CSS de thème clair et sombre à partir d'une seule couleur primaire. Shadcn Studio ajoute un éditeur de thème plus large avec des contrôles, des aperçus, des préréglages et des méthodes d'installation. Identity Forge regroupe les tokens sémantiques avec des directives de design écrites et des artefacts de livraison pour agents.

La comparaison utilise quatre états de preuve. "Documenté" signifie qu'une source figée établit la capacité. "Partiel" signifie que la source établit une capacité plus étroite, avec la limite précisée. "Non documenté" signifie que les preuves disponibles n'établissent pas cette capacité, ce qui n'est pas une preuve d'absence. "Non applicable" concerne un champ qui ne correspond pas à l'artefact.

• Rôles sémantiques : non documenté. Les pages citées établissent des composants personnalisables et du code ouvert, mais pas un contrat de sortie de tokens sémantiques.
• Sortie clair et sombre : non documenté. La page d'accueil inclut des images d'interface claire et sombre, mais cela ne documente pas le contenu d'un thème généré ou distribué.
• Contrôles typographiques : non documenté. Les preuves citées n'établissent pas les contrôles typographiques comme faisant partie d'un contrat de sortie.
• Directives d'espacement et de mise en page : non documenté. Les preuves citées n'établissent pas de règles d'espacement ou de mise en page exportées.
• Directives de composants : partiel. Les sources documentent des composants open-code personnalisables et une interface composable commune, mais pas de règles d'utilisation du design exportées.
• Aperçus : partiel. La page d'accueil montre des surfaces d'interface représentatives, mais les preuves n'établissent pas de thème interactif ou de flux de travail d'aperçu à l'exportation.
• Forme d'export ou de livraison : documenté. La documentation décrit le code de composant ouvert distribué via un schéma de fichiers plats et une CLI.
• Livraison par registre : non documenté. Les extraits cités n'établissent pas cette route de livraison.
• Documentation lisible par un agent : partiel. L'introduction indique que les modèles d'IA peuvent lire le code ouvert et l'API cohérente, mais elle n'établit pas de document distinct de règles de design.

• Rôles sémantiques : non documenté. La page documente les variables CSS générées mais n'expose pas assez de la sortie pour vérifier un ensemble de rôles basés sur la signification.
• Sortie clair et sombre : documenté. Le générateur indique qu'il crée les deux modes à partir d'une seule couleur primaire.
• Contrôles typographiques : documenté. La page propose des choix de polices distincts pour le corps de texte et les titres.
• Directives d'espacement et de mise en page : non documenté. La page n'établit pas de règles écrites d'espacement ou de mise en page.
• Directives de composants : non documenté. Les écrans d'aperçu stylisés n'établissent pas d'instructions d'utilisation de composants exportées.
• Aperçus : documenté. Le générateur fournit des aperçus en direct sur des pages d'accueil, des tableaux de bord et des graphiques.
• Forme d'export ou de livraison : documenté. Il copie les variables CSS Tailwind v4 couvrant les couleurs, les polices, le rayon et les ombres.
• Livraison par registre : non documenté. La page citée n'établit pas l'installation par registre pour le thème généré.
• Documentation lisible par un agent : non documenté. Les preuves n'établissent pas de brief de design ou d'un autre document de règles livré avec le thème.

• Rôles sémantiques : partiel. Le générateur documente des contrôles nommés incluant primary et destructive, mais les preuves n'établissent pas un inventaire complet des rôles sémantiques.
• Sortie clair et sombre : documenté. Le générateur documente la personnalisation et l'export du thème shadcn au sein de son flux de travail.
• Contrôles typographiques : documenté. Sa documentation inclut un onglet typographie.
• Directives d'espacement et de mise en page : non documenté. Les pages citées n'établissent pas de règles d'espacement ou de mise en page exportées.
• Directives de composants : non documenté. Les aperçus en temps réel montrent des effets visuels, mais les preuves n'établissent pas de règles écrites d'utilisation de composants dans l'export.
• Aperçus : documenté. Le générateur fournit des aperçus en temps réel pour les composants, les blocs et les modèles.
• Forme d'export ou de livraison : documenté. Les sources décrivent la copie de la sortie, la configuration manuelle et une route de registre.
• Livraison par registre : documenté. La documentation identifie l'installation par registre comme une option Pro et la configuration manuelle comme une autre route.
• Documentation lisible par un agent : non documenté. La génération de thèmes assistée par IA est documentée, mais cela diffère de l'exportation de règles pour un autre agent de codage.

• Rôles sémantiques : documenté. Identity Forge documente 28 rôles de couleur basés sur la signification dans les deux modes et les exports CSS, Tailwind et DTCG.
• Sortie clair et sombre : documenté. Le guide des tokens sémantiques et les preuves du kit public décrivent des valeurs distinctes pour le clair et le sombre.
• Contrôles typographiques : documenté. Les données du kit public incluent des rôles de type, des familles, des graisses et une étiquette d'échelle.
• Directives d'espacement et de mise en page : documenté. Le guide DESIGN.md indique que ses briefs générés incluent des règles d'espacement et de mise en page.
• Directives de composants : documenté. Le guide DESIGN.md décrit les traitements de composants et des contraintes d'utilisation explicites dans le brief écrit.
• Aperçus : documenté. Les pages du kit public montrent les kits sur des surfaces d'interface représentatives.
• Forme d'export ou de livraison : documenté. Les sources du produit décrivent DESIGN.md ainsi que les formats de tokens CSS, Tailwind, shadcn et DTCG.
• Livraison par registre : documenté. Les guides propriétaires documentent l'installation dans le registre shadcn aux côtés des routes CLI et MCP.
• Documentation lisible par un agent : documenté. DESIGN.md fournit des directives écrites liées aux tokens du kit.

Il n'y a pas de vainqueur universel dans cette cartographie. Un générateur ciblé est plus adapté lorsqu'un projet shadcn existant a seulement besoin de nouvelles variables visuelles et d'un aperçu. Des règles plus larges deviennent utiles lorsque les développeurs ou les agents doivent prendre de nouvelles décisions d'interface sans avoir à deviner répétitivement le système prévu.

Appliquez cette fiche de travail sur un export réel. Il s'agit d'une inspection réalisée par le lecteur, et non d'un benchmark des outils ci-dessus. Utilisez le même contenu d'exemple pour chaque candidat afin que les différences proviennent des artefacts et non de différents écrans de test.

• Contenu de test : arrière-plan de page, texte standard et atténué, actions primaires et destructives, un champ de saisie bordé, un contrôle sélectionné et un état de focus au clavier.
• Inspection : notez si les noms décrivent une fonction, telle que background, foreground, primary, destructive, border et ring, ou seulement des valeurs visuelles. Associez chaque rôle clair inspecté à son équivalent sombre.
• Condition d'échec : un composant nécessite une teinte brute car aucun rôle approprié n'existe, un rôle clair n'a pas de contrepartie sombre, ou les états destructifs et de focus empruntent un rôle non lié.

• Contenu de test : boutons primaires et secondaires, champs de saisie désactivés et en erreur, cartes, popovers, navigation, un tableau avec des lignes sélectionnées et survolées, et un graphique avec plusieurs séries.
• Inspection : tracez les couleurs visibles vers les rôles exportés. Vérifiez les paires foreground/background, les bordures, les indicateurs de focus, les overlays, les états sélectionnés et les rôles de séries de graphiques.
• Condition d'échec : l'écran nécessite des valeurs improvisées, un rôle sert des fonctions conflictuelles, ou un état devient indiscernable dans un mode. Notez cela comme une lacune dans l'export candidat, et non comme une preuve de ce que l'outil peut supporter.

• Contenu de test : titre de page, titre de section, corps de texte, étiquette de formulaire, texte d'aide, valeurs de tableau et un champ de code ou d'identifiant si pertinent.
• Inspection : notez si l'artefact mappe les familles, les graisses, les tailles, les hauteurs de ligne et le lettrage à des rôles nommés ou s'il fournit seulement des valeurs font-family.
• Condition d'échec : les implémenteurs doivent inventer des graisses ou des traitements, un rôle fait référence à une graisse indisponible, ou les valeurs exportées entrent en conflit avec les instructions écrites.

• Contenu de test : formulaire étroit, grille de cartes, tableau dense, en-tête de page et navigation responsive.
• Inspection : recherchez des règles couvrant la largeur du contenu, les gouttières, l'espacement des sections, la densité des composants, le comportement de la grille et les changements responsives. Vérifiez si ces règles restent disponibles après l'export ou l'installation.
• Condition d'échec : un aperçu implique une mise en page que l'artefact ne décrit jamais, l'export supprime les règles écrites, ou un autre implémenteur doit déduire la densité et la structure uniquement à partir des images.

Un agent de codage ne peut utiliser que les directives qui atteignent son contexte de travail. Avant de qualifier un export de transfert pour agent, répondez à ces questions pour l'artefact et le projet réels.

• Hypothèses de framework : Quel contexte shadcn, Tailwind, framework ou bibliothèque de composants attend-il ? Notez les versions lorsque la source les fournit.
• Route d'installation : Le projet reçoit-il du CSS copié, du code de composant, un bundle appliqué via CLI, un élément de registre, un artefact livré par MCP, ou une combinaison ?
• Mappage token-composant : L'implémenteur peut-il identifier les rôles pour les boutons, les champs de saisie, les cartes, les popovers, la navigation, les tableaux, les graphiques, les actions destructives et les états de focus ?
• Choix typographiques : Les familles, les rôles et les graisses disponibles sont-ils explicites ?
• Règles d'espacement et de mise en page : Le transfert décrit-il l'agencement de la page et des composants, ou seulement les valeurs du thème ?
• Contraintes d'utilisation : Explique-t-il quand un traitement doit ou ne doit pas être utilisé ?
• Lacunes connues : Quelles valeurs ou règles nécessitent encore qu'un designer, un développeur ou un agent décide ?

Un DESIGN.md n'est utile que si le flux de travail le place là où l'agent cible le lit. Un élément de registre peut installer des valeurs sans nécessairement placer la justification écrite dans le même contexte. Inspectez les deux chemins au lieu de supposer qu'un artefact installé transporte l'intégralité du transfert.

Le kit public Ambient Sage est un exemple limité d'un transfert plus large. Ses données publiées listent 28 tokens de couleur sémantiques pour les modes clair et sombre. La page fournit également un DESIGN.md et identifie des chemins d'installation incluant la CLI Identity Forge et le registre shadcn. Ce sont des propriétés observées de ce kit, et non une preuve que ses choix visuels conviennent à chaque produit.

La typographie publiée assigne Plus Jakarta Sans aux rôles heading et body avec les graisses 400, 500, 600 et 700. JetBrains Mono a le rôle mono avec les graisses 400, 500 et 700. L'étiquette d'échelle est compact-product. Les sources du projet de police établissent que les familles nommées existent, mais elles ne montrent pas que ce couplage, cet ensemble de graisses ou cette échelle est préférable pour chaque implémentation.

Les preuves publiques identifient l'artefact et sa couverture déclarée. L'adoption nécessite toujours une inspection. Vérifiez si l'export choisi préserve les 28 rôles dans les deux modes, si le projet charge les graisses listées et si le DESIGN.md atteint la personne ou l'agent censé le suivre. Ensuite, tracez les rôles à travers les composants de la fiche de travail. Cet article n'a pas réalisé de benchmark comparatif.

• Choisissez le CSS copié lorsque la tâche est une mise à jour visuelle et que le projet possède déjà des règles de composants, de typographie, d'espacement et de mise en page.
• Choisissez un éditeur de thème ou un préréglage réutilisable lorsque les projets shadcn ont besoin de variables visuelles et d'aperçus cohérents, tandis que des directives produit plus larges existent ailleurs.
• Choisissez un design system prêt pour l'implémentation lorsque les implémenteurs ont besoin de rôles sémantiques partagés ainsi que de directives explicites pour la typographie, l'espacement, la mise en page et les composants.
• Choisissez un transfert pour agent lorsqu'un constructeur IA doit conserver ces décisions pendant l'implémentation. Vérifiez comment les tokens et les règles écrites entrent dans son contexte.

Prenez un export candidat et passez-le au crible avec la fiche de travail avant de l'ajouter au projet. Les décisions non résolues montreront si l'artefact actuel est suffisant ou si le travail nécessite un transfert plus large.

• The Foundation for your Design System - shadcn/ui: Présente des composants open-code personnalisables et des surfaces d'interface représentatives en modes clair et sombre.
• Introduction - shadcn/ui: Documente le code ouvert, la composition, le schéma de fichiers plats et la distribution via CLI, ainsi qu'une API lisible par les outils d'IA.
• Shadcn Theme Generator | Live Preview, Copy Theme CSS: Documente la génération à partir d'une couleur primaire, les thèmes clair et sombre, les contrôles de police, les préréglages de rayon, les aperçus en direct et la sortie de variables CSS Tailwind v4.
• Design Stunning UIs Faster with Shadcn Theme Generator: Documente les préréglages, la personnalisation en temps réel, les contrôles de typographie, les contrôles de couleurs nommées, la validation du contraste, les aperçus et l'import ou l'export de thèmes.
• Shadcn Theme Generator Documentation: Documente les contrôles du thème, la copie de la sortie, la configuration manuelle et l'installation du registre Pro.
• Identity Forge: Documente des kits contenant des polices, des tokens sémantiques, de l'espacement, des directives DESIGN.md, des aperçus et des chemins de livraison pour agents.
• Ambient Sage Design Kit: Fournit des preuves publiques pour l'exemple concret : tokens sémantiques, rôles et graisses typographiques, étiquette d'échelle de produit compact, DESIGN.md, exports et cibles d'installation.
• Semantic color tokens explained: Documente les 28 rôles sémantiques clair et sombre d'Identity Forge ainsi que les formats d'export CSS, Tailwind et DTCG.
• How to generate a DESIGN.md (and what it is): Documente la couverture de DESIGN.md incluant l'intention de design, les références de tokens, la typographie, l'espacement, la mise en page, le traitement des composants, les motifs et les contraintes d'utilisation.
• Design systems for AI coding agents: Documente la livraison de tokens et de DESIGN.md via les routes MCP, CLI et le registre shadcn.
• Plus Jakarta Sans: Fournit la source du projet pour la famille Plus Jakarta Sans nommée dans l'exemple Ambient Sage.
• JetBrains Mono: Fournit la source du projet pour la famille JetBrains Mono nommée dans l'exemple Ambient Sage.