Pourquoi Lovable a besoin d'un design system
Lovable excelle pour transformer un prompt en application fonctionnelle, mais son apparence par défaut est générique et tend à diverger à mesure que l'app s'étoffe : chaque nouvelle fonctionnalité entraîne une nouvelle décision de style. Comme il utilise Tailwind et shadcn, il peut s'appuyer sur un ensemble de tokens réels et suivre des règles écrites ; il suffit de rendre ces règles persistantes pour qu'elles s'appliquent à chaque génération, et pas seulement à celle où vous les avez mentionnées.
Le kit à lui fournir
Mauve Broadcast
Live renderRendered from the kit's actual tokens, fonts, and treatments
Typography
Anton + Space Mono
Color system
28 semantic roles, light + dark
Agent outputs
DESIGN.md, CSS, Tailwind, shadcn
Fournir le kit à Lovable
- 1
Placer le DESIGN.md dans le Knowledge du projet
Ouvrez la page du kit dans la galerie (par exemple, /kits/ambient-sage), copiez les parties du DESIGN.md contenant les règles (intention, motifs, à faire et à ne pas faire, traitement des composants) dans Project settings > Knowledge. Le Knowledge est limité à 10 000 caractères alors qu'un DESIGN.md complet peut atteindre presque trois fois ce volume ; collez donc les règles et laissez l'installation via le registre à l'étape suivante gérer les valeurs exactes des tokens. Lovable conserve le Knowledge comme contexte persistant pour chaque génération.
- 2
Se connecter à GitHub et appliquer les tokens
Utilisez l'intégration GitHub de Lovable, puis, dans le repo connecté, exécutez la commande du registre du kit pour installer ses variables CSS dans le thème shadcn :
npx shadcn add https://identityforge.io/r/ambient-sage.json - 3
Ou collez les variables CSS dans le chat
Vous préférez rester dans Lovable ? Copiez l'export des variables CSS depuis la page du kit et demandez à Lovable de configurer le
:rootet le.darkde votre feuille de style globale avec exactement ces valeurs. - 4
Construire sur le système
Promptz comme d'habitude ; Lovable applique désormais vos tokens et respecte le DESIGN.md présent dans le Knowledge.
Add a dashboard. Use the design tokens and follow the DESIGN.md in Project Knowledge. Do not add new colors or fonts.
Les fonctionnalités de design natives de Lovable
Lovable propose également des primitives utiles : les Skills (des playbooks à la demande que l'agent applique aux tâches correspondantes), Design guidance (choix parmi des aperçus de design avant la construction) et, pour les plans Enterprise, des projets de design system natifs qui poussent les tokens et composants vers les apps consommatrices. Le Knowledge combiné au registre reste la méthode indépendante du plan et garantit l'identité de vos tokens sur tous vos outils.
Le Knowledge assure la persistance
La raison principale pour laquelle un constructeur IA ignore votre design system est que les règles ont été mentionnées une seule fois puis oubliées. Placer les règles de design dans le Knowledge de Lovable en fait une instruction permanente, garantissant ainsi la cohérence à mesure que l'app évolue.
Une URL, tout le thème
Chaque kit public expose un élément de registre shadcn stable à l'adresse https://identityforge.io/r/<slug>.json. Cette URL contient les 28 rôles sémantiques en modes clair et sombre, Lovable n'a donc jamais besoin d'improviser les états de survol, le texte atténué, les bordures ou les couleurs de graphiques. Consultez l'article explication des tokens de couleurs sémantiques pour comprendre ces rôles et leur importance.
La même approche fonctionne dans v0 et Bolt. Pour les agents de code basés sur le terminal, consultez le guide pillar.
FAQ
Comment donner un design system à Lovable ?
Placez les règles de design du kit dans le Knowledge du projet Lovable pour qu'elles s'appliquent à chaque prompt (le Knowledge est limité à 10 000 caractères, collez donc les sections de règles et non le fichier entier), puis appliquez les tokens du kit : soit en exécutant npx shadcn add https://identityforge.io/r/<slug>.json dans le repo connecté à GitHub, soit en collant les variables CSS du kit dans la feuille de style du projet.
Pourquoi mettre le DESIGN.md dans le Knowledge plutôt que dans un prompt ?
Le Knowledge est un contexte permanent qui s'applique à chaque génération. Un prompt ponctuel est oublié dès le message suivant, c'est pourquoi les constructeurs s'éloignent de la charte graphique. Le Knowledge maintient les règles de design en vigueur pendant la croissance de l'app.
Dois-je connecter GitHub ?
Uniquement pour la méthode shadcn add. Vous pouvez sinon coller directement les variables CSS exportées du kit et demander à Lovable de configurer la feuille de style globale avec ces valeurs.
Sources
- Knowledge - Lovable Docs : Knowledge permet de définir des instructions persistantes par projet ou espace de travail, via Project settings > Knowledge, avec une limite de 10 000 caractères.
- Design systems - Lovable Docs : Lovable propose des projets de design system natifs pour les forfaits Enterprise, permettant de pousser des tokens et des composants vers les projets consommateurs.
Sources
- Knowledge - Lovable Docs: Knowledge permet de définir des instructions persistantes par projet ou espace de travail, via Project settings > Knowledge, avec une limite de 10 000 caractères.
- Design systems - Lovable Docs: Lovable propose des projets de design system natifs pour les forfaits Enterprise, permettant de pousser des tokens et des composants vers les projets consommateurs.