shadcn

Présentation du skill shadcn

À quoi sert le skill shadcn

Le skill shadcn aide un assistant IA à travailler correctement dans de vrais projets shadcn/ui : repérer les composants, les installer avec la bonne CLI, composer des écrans à partir de primitives existantes et éviter les erreurs d’API fréquentes entre presets et familles de composants. Il devient particulièrement utile quand vous attendez plus que « génère-moi un bouton » et que vous avez besoin d’une sortie qui respecte components.json, les éléments de registry déjà installés, votre template, ainsi que les différences entre base et radix.

À qui s’adresse ce skill shadcn

Ce skill shadcn convient particulièrement à :

• des développeurs qui utilisent déjà shadcn/ui
• des équipes qui adoptent un preset ou un workflow UI piloté par registry
• des personnes qui demandent à une IA d’ajouter ou de refactorer des formulaires, dialogs, pages de réglages, dashboards ou éléments de thème
• toute personne qui veut que l’assistant inspecte le contexte du projet avant d’écrire du JSX

Si vous n’utilisez ni shadcn/ui, ni components.json, ni la CLI shadcn, ce skill sera probablement trop spécifique.

Le vrai besoin auquel il répond

Les utilisateurs ne veulent pas seulement un résumé du repo. Ils veulent que l’assistant :

1. détecte la configuration shadcn du projet,
2. choisisse des composants existants avant d’en inventer de nouveaux,
3. utilise les bonnes commandes CLI et les flags documentés,
4. compose l’UI selon les patterns recommandés par la bibliothèque,
5. évite les cassures subtiles comme une mauvaise composition de trigger, des wrappers de groupe manquants ou un branchement incorrect de la validation de formulaire.

C’est là que ce skill shadcn apporte une vraie valeur ajoutée par rapport à un prompt UI générique.

Ce qui distingue shadcn d’un prompt générique

Les différenciateurs les plus forts sont très concrets :

• il part du contexte projet fourni par npx shadcn@latest info --json
• il privilégie search, view et docs avant toute implémentation custom
• il encode les règles du projet à partir de fichiers comme rules/composition.md, rules/forms.md, rules/styling.md et rules/base-vs-radix.md
• il couvre le theming et le changement de preset, pas seulement des snippets de composants
• il inclut des recommandations MCP pour la recherche dans les registries et les workflows d’installation

En bref, le skill shadcn consiste moins à « écrire du React » qu’à « écrire le bon React pour cette configuration shadcn ».

Contraintes importantes avant adoption

Avant de vous appuyer sur ce skill, gardez en tête ces contraintes :

• il suppose un accès à la CLI shadcn via l’exécuteur de paquets du projet : npx, pnpm dlx ou bunx --bun
• il est limité aux flags CLI documentés ; le skill signale explicitement qu’il ne faut pas en inventer
• beaucoup de bonnes sorties dépendent d’un components.json valide
• les détails d’API peuvent varier selon le preset et selon base vs radix, donc réutiliser des exemples à l’aveugle peut mener à des erreurs

Comment utiliser le skill shadcn

Contexte d’installation pour le skill shadcn

Ajoutez le skill à votre environnement IA via le flux d’installation standard de l’annuaire, puis utilisez-le dans un repo qui contient réellement — ou a vocation à contenir — une configuration shadcn. En pratique, la contrainte côté dépôt est plus importante que la commande d’installation du skill : l’assistant doit avoir accès aux fichiers du projet et pouvoir exécuter les commandes de la CLI shadcn.

Dans le projet cible, les commandes d’exécution pertinentes sont :

• npx shadcn@latest info --json
• npx shadcn@latest search <query>
• npx shadcn@latest view <item>
• npx shadcn@latest docs <component>
• npx shadcn@latest add <component>

Remplacez par pnpm dlx shadcn@latest ou bunx --bun shadcn@latest si cela correspond au gestionnaire de paquets du projet.

Lisez d’abord ces fichiers avant de demander une sortie

Pour utiliser shadcn rapidement et correctement, inspectez ces fichiers à peu près dans cet ordre :

1. SKILL.md
2. cli.md
3. rules/composition.md
4. rules/base-vs-radix.md
5. rules/forms.md
6. rules/styling.md
7. customization.md
8. mcp.md

Pourquoi cet ordre fonctionne :

• SKILL.md définit les conditions de déclenchement et le workflow
• cli.md évite les commandes et flags supposés
• les fichiers rules/ capturent les erreurs que la génération de code générique fait souvent
• customization.md devient important quand vous avez besoin d’un styling compatible avec le thème, et non de simples hacks de couleurs Tailwind
• mcp.md compte si votre assistant peut parcourir les registries via MCP plutôt que via des commandes shell

Commencez chaque tâche shadcn par une découverte du projet

La meilleure première étape, de loin, est :

npx shadcn@latest info --json

Cela indique à l’assistant ce qui est déjà configuré, y compris le contexte composant et le contexte projet. C’est particulièrement utile pour :

• vérifier si components.json existe
• identifier les composants déjà installés
• détecter les détails de configuration qui changent les choix de code valides
• confirmer l’exécuteur de paquets et éviter de montrer de mauvaises commandes

Si vous sautez cette étape, le skill shadcn se rapproche beaucoup plus d’un prompt générique.

Transformer un objectif vague en prompt shadcn solide

Prompt faible :

Build me a profile dialog with shadcn.

Meilleur prompt :

In this existing shadcn/ui app, inspect components.json and run npx shadcn@latest info --json first. We use the radix setup and lucide-react. Create a profile edit dialog using existing shadcn components only where possible. Include avatar, name, bio, Save/Cancel actions, accessible title, semantic tokens, and no raw color classes. If a component is missing, tell me the exact shadcn add command before generating code.

Pourquoi cette formulation est meilleure :

• elle impose une découverte du projet
• elle précise un comportement sensible au preset
• elle fixe des contraintes d’icônes et de styling
• elle demande les étapes d’installation si des dépendances manquent

Utilisez search et docs avant d’écrire du code custom

Un bon workflow shadcn ressemble à ceci :

1. rechercher des composants existants dans les registries,
2. inspecter la documentation et les exemples,
3. ajouter ce qui manque,
4. composer l’écran.

Commandes pratiques :

npx shadcn@latest search dialog
npx shadcn@latest docs dialog
npx shadcn@latest view @shadcn/dialog

C’est particulièrement important pour les formulaires, overlays, éléments de navigation et empty states, où les règles du skill privilégient les patterns de la bibliothèque plutôt que des structures div improvisées.

Composez les écrans à partir de briques existantes

Le skill shadcn est le plus efficace quand vous demandez de la composition, pas une UI custom monolithique. Les cadrages de tâche utiles incluent :

• « page de réglages = Tabs + Card + contrôles de formulaire »
• « dashboard = Sidebar + Card + Chart + Table »
• « empty state = composant Empty, pas une div centrée maison »
• « callout = Alert, pas des encadrés à bordure bricolés »

Cela reflète le workflow préféré du skill : utiliser d’abord les composants existants, puis n’adapter les variantes et wrappers qu’en cas de besoin.

Respectez les différences entre base et radix

L’un des plus gros freins à l’adoption vient de l’idée que tous les exemples shadcn seraient interchangeables. Ce n’est pas le cas.

Le skill inclut des indications explicites pour base vs radix, notamment sur :

• asChild vs render
• les différences de composition des triggers
• nativeButton={false} dans certains cas spécifiques à base
• les écarts d’API sur des composants comme Select, ToggleGroup, Slider et Accordion

Si votre prompt ne précise pas la configuration utilisée, demandez à l’assistant de la détecter via npx shadcn@latest info.

Utilisez des règles de styling qui tiennent au changement de thème

Avec shadcn pour UI Design, de meilleurs résultats viennent des tokens sémantiques et d’un theming piloté par variables CSS, pas de couleurs Tailwind codées en dur.

À privilégier :

• bg-background
• text-foreground
• text-muted-foreground
• text-destructive

À éviter par défaut :

• bg-red-500
• text-gray-400
• trop d’overrides dark: manuels

C’est important parce que customization.md explique que les composants héritent des variables CSS. Si l’assistant utilise des tokens sémantiques, votre design s’adaptera beaucoup plus proprement aux thèmes clair/sombre et aux presets.

Gérez les formulaires à la manière shadcn

Les evals et les règles montrent clairement que la qualité des formulaires est un sujet central. Un bon usage de shadcn pour les formulaires implique généralement :

• d’utiliser les patterns de mise en page de champs fournis au lieu d’empiler des div brutes
• de marquer l’état invalide avec data-invalid et aria-invalid
• d’utiliser Switch pour des préférences on/off indépendantes
• de préférer les espacements gap-* à space-y-* lorsque les règles le demandent

Si votre tâche inclut de la validation, dites-le explicitement. Sinon, beaucoup d’assistants génèrent des formulaires plausibles visuellement, mais incohérents avec la bibliothèque.

Utilisez MCP quand votre éditeur le prend en charge

Si votre environnement prend en charge MCP, le skill shadcn peut devenir plus fiable pour les opérations liées aux registries. mcp.md documente des outils pour :

• lister les registries du projet
• rechercher des éléments dans la registry
• afficher les détails d’un élément et le contenu de ses fichiers
• récupérer des exemples
• installer des éléments

C’est utile si vous voulez que l’assistant parcoure les registries de façon conversationnelle plutôt que de dépendre uniquement de la sortie de la CLI. Cela ne remplace pas info --json pour la configuration du projet.

Modèle de prompt pratique pour utiliser shadcn

Utilisez ce modèle si vous voulez une sortie de meilleure qualité :

Use the shadcn skill for this task. First inspect the project with `npx shadcn@latest info --json` and read `components.json` if present. Confirm whether this project uses `base` or `radix`. Search for existing components before building custom UI. If something is missing, give the exact documented `shadcn add` command. Then generate the component using semantic tokens, correct composition rules, and the project’s icon library.

Goal: [what you want to build]
Screen context: [page/dialog/form/dashboard/etc.]
Existing components: [if known]
Framework/template: [Next.js/Vite/Astro/etc.]
Constraints: [icons, validation, dark mode, accessibility, no raw colors, no guessed APIs]
Output needed: [component code, install commands, explanation, refactor diff]

FAQ sur le skill shadcn

Ce skill shadcn sert-il uniquement à installer des composants ?

Non. Les tâches shadcn install en font partie, mais le skill va plus loin : inspection du projet, recherche dans les registries, composition de composants, theming, debugging, changement de preset et refactors corrects du point de vue API entrent tous dans son périmètre.

Le skill shadcn est-il adapté aux débutants ?

Oui, si vous êtes déjà à l’aise avec React et un gestionnaire de paquets. Le skill réduit les approximations en orientant l’assistant vers les bonnes commandes et les bonnes règles. Il l’est moins si vous avez besoin d’une introduction complète à React, Tailwind ou aux design systems depuis zéro.

Quand shadcn est-il préférable à un prompt normal ?

Utilisez le skill shadcn lorsque la justesse dépend du contexte du projet :

• présence d’un components.json
• correspondance avec les composants installés
• comportement base vs radix
• usage exclusif des flags CLI documentés
• préservation des tokens de thème et des règles de composition de la bibliothèque

Un prompt classique peut produire du JSX crédible, mais il risque davantage d’oublier des étapes d’installation ou de mal utiliser les API des composants.

Quand ne faut-il pas utiliser le skill shadcn ?

Évitez-le si :

• votre projet n’utilise pas shadcn/ui
• vous avez seulement besoin de maquettes HTML/CSS génériques
• vous voulez une réponse indépendante de tout design system
• l’assistant ne peut ni inspecter les fichiers ni exécuter des commandes, et vous ne pouvez pas fournir le contexte nécessaire manuellement

Dans ces cas-là, un skill frontend plus général sera souvent plus pertinent.

Le skill aide-t-il pour les décisions shadcn en UI Design ?

Oui, surtout sur la composition et le theming. Il pousse l’assistant vers des primitives réutilisables, des tokens de couleur sémantiques, de bons patterns d’overlay et des structures de composants plus faciles à maintenir que des layouts artisanaux ponctuels.

Qu’est-ce qui casse le plus souvent l’usage de shadcn dans les sorties IA ?

Les échecs les plus fréquents sont :

• l’invention de flags CLI non pris en charge
• une mauvaise composition de trigger entre base et radix
• la création d’une UI custom au lieu d’utiliser un composant existant de la registry
• un styling à base de couleurs brutes qui entre en conflit avec le système de thème
• l’omission de sous-composants requis comme les titres, groupes ou fallbacks

Ce sont précisément les points que ce skill cherche à fiabiliser.

Comment améliorer le skill shadcn

Donnez dès le départ au skill shadcn le contexte manquant

L’amélioration la plus rentable vient de la qualité des entrées. Incluez :

• le framework ou template (next, vite, astro, etc.)
• si components.json existe
• base ou radix si c’est déjà connu
• le jeu d’icônes actuel
• le composant ou l’écran visé
• si la tâche porte sur une installation, un refactor ou un bugfix

Une seule phrase de contexte concret peut suffire à éviter que l’assistant choisisse les mauvaises API.

Demandez les commandes avant le code si des composants risquent de manquer

Si votre projet n’a peut-être pas encore le composant nécessaire, formulez la demande ainsi :

Before writing code, check whether the required shadcn components are already present. If not, give me the exact add command and wait.

Cela améliore la sortie parce que les changements d’environnement sont séparés de l’implémentation, ce qui rend le résultat plus fiable et plus facile à appliquer.

Exigez une sortie consciente des règles pour les composants fragiles

Pour les formulaires, dialogs, dropdowns, sheets, drawers et selects, demandez explicitement à l’assistant de suivre les fichiers de règles. Exemple :

Follow the shadcn rules for composition, forms, and base-vs-radix differences. Do not simplify structure if it changes the component API.

C’est important, car beaucoup de générations médiocres ont l’air correctes visuellement, tout en cassant l’accessibilité ou les contrats de composition.

Améliorez l’usage de shadcn en précisant les contraintes de design

Un bon prompt UI ne se limite pas à « fais quelque chose de moderne ». Ajoutez des contraintes comme :

• uniquement des tokens sémantiques
• aucune utility de palette brute
• le dark mode doit fonctionner sans overrides manuels
• utiliser les variantes existantes avant d’ajouter des classes custom
• privilégier les empty states, alerts, separators, badges et skeletons de la bibliothèque

Dans un contexte shadcn pour UI Design, ces détails améliorent concrètement la qualité du premier jet.

Itérez avec des corrections ciblées, pas des réécritures complètes

Après la première sortie, évitez de dire seulement « recommence ». Préférez :

• « Refactor this to use installed shadcn components only. »
• « Make this valid for base, not radix. »
• « Replace raw color classes with semantic tokens. »
• « Add the missing title/fallback/group wrappers required by shadcn. »
• « Show the exact shadcn add commands for anything assumed. »

Vous conservez ainsi ce qui est bon tout en corrigeant les parties les plus susceptibles d’être fausses.

Validez par rapport aux signaux les plus forts du repo

Pour gagner en confiance, comparez la sortie avec :

• cli.md pour les commandes et flags
• rules/composition.md pour la structure
• rules/base-vs-radix.md pour la justesse des API
• rules/forms.md pour les patterns de validation et de mise en page
• rules/styling.md et customization.md pour un styling compatible avec le thème
• evals/evals.json pour voir à quoi ressemble une bonne sortie en pratique

C’est le moyen le plus rapide de vérifier si le skill shadcn produit une sortie alignée sur le repo, plutôt qu’un simple code UI générique.