Extraire le Système de Design depuis le Code Frontend
Analyse le code source frontend pour extraire un document complet de système de design (DESIGN.md) qui capture le langage visuel du projet — couleurs, typographie, espacements, motifs de composants et principes de mise en page — directement depuis les fichiers sources, sans avoir besoin de builder ou de rendre l'application.
Pourquoi Cela Existe
La compétence design-md fonctionne à partir du HTML rendu. Mais souvent vous avez un codebase et vous voulez comprendre son système de design avant même de pouvoir lancer l'application — les dépendances peuvent être manquantes, la build peut être cassée, ou vous voulez simplement un audit rapide. Cette compétence lit les fichiers sources eux-mêmes : feuilles de style, fichiers composants, configurations de thème et configurations Tailwind. C'est plus rapide et ça fonctionne partout.
Quand l'Utiliser
- L'utilisateur a un codebase frontend et veut extraire ou documenter son système de design
- L'utilisateur veut migrer l'identité visuelle d'un projet dans Stitch
- L'utilisateur demande de "auditer le style" ou "comprendre le langage de design" d'un dépôt
- L'utilisateur veut créer un DESIGN.md à partir d'un code source existant
- L'application ne peut pas être buildée/rendue mais le code source est disponible
- L'utilisateur veut unifier ou réconcilier des styles incohérents dans un codebase
Prérequis
- Accès au répertoire source du projet frontend
- Aucune dépendance de build ou d'exécution nécessaire — cette compétence lit uniquement les fichiers sources
Flux de Travail
Phase 1 : Découverte du Projet
Commencez par comprendre sur quoi vous travaillez. Cela détermine les modèles d'extraction à utiliser.
1. Détecter le Framework et la Stack
Scannez la racine du projet pour les fichiers indicateurs :
| Fichier Indicateur | Framework / Outil |
|---|---|
package.json avec react | React / Next.js |
package.json avec vue | Vue / Nuxt |
package.json avec svelte | Svelte / SvelteKit |
package.json avec @angular/core | Angular |
tailwind.config.js/ts | Tailwind CSS |
postcss.config.js | Pipeline PostCSS |
styled-components ou @emotion dans les dépendances | CSS-in-JS |
Fichiers .css / .scss / .less uniquement | CSS / SASS brut |
theme.js / theme.ts / tokens.js | Fichiers de tokens de design |
Lisez package.json en premier — il révèle le framework, les outils CSS et les éventuelles bibliothèques de tokens de design (ex : style-dictionary, @chakra-ui/react, @mui/material, ant-design). Ce contexte vous indique où chercher les informations de style.
2. Cartographier l'Arbre Source
Identifiez les répertoires et fichiers clés que vous allez analyser :
src/
├── components/ ← Styles des composants
├── styles/ ← Feuilles de style globales
├── theme/ ← Définitions de thèmes, tokens
├── assets/ ← Polices, images
├── app.css ← Styles racine
└── index.css ← CSS d'entrée
Vérifiez également :
tailwind.config.js/tailwind.config.ts— Couleurs, polices, espacements personnalisésglobals.css/global.css— Propriétés personnalisées CSS (variables)- Tout fichier
theme.*outokens.* - Configuration de la bibliothèque de composants (ex :
chakra-theme.ts,vuetify.config.ts)
3. Lire les Guides Propres au Framework
Consultez la référence appropriée pour les modèles d'extraction :
- React / Next.js / Tailwind → references/react-tailwind.md
- Vue / Nuxt → references/vue.md
- Svelte / SvelteKit → references/svelte.md
- Angular → references/angular.md
- CSS / SASS / Less brut → references/plain-css.md
Ces références contiennent des modèles propres au framework pour localiser les couleurs, la typographie, les espacements et les styles de composants. Lisez celui qui correspond avant de continuer.
Phase 2 : Extraction Approfondie
Parcourez chaque dimension de design de manière systématique. Pour chacune, collectez les données brutes depuis les fichiers sources, puis synthétisez-les en langage descriptif.
L'objectif n'est pas de vider chaque propriété CSS — c'est de comprendre l'intention derrière les choix de style et de les décrire dans un langage humain et éditorial qu'un autre designer (ou Stitch) peut utiliser pour recréer la même sensation visuelle.
1. Thème Visuel & Atmosphère
Lisez d'abord les styles les plus larges pour comprendre l'ambiance générale :
- Arrière-plan racine : Quel est l'arrière-plan du
bodyou de l'élément racine ? Crème clair (#f-range) signale un aspect aéré/propre ; foncé (#0-#2 range) signale une ambiance sombre/dramatique. - Philosophie des espaces blancs : Les valeurs d'espacement sont-elles généreuses (32px+) ou serrées ? Vérifiez les valeurs de
padding/marginsur les conteneurs racines, les wrappers de section et les composants carte. - Densité : Comptez les composants par page/section. Peu avec espace = minimaliste ; beaucoup serrés = dense en informations.
- Température des couleurs : Les neutres sont-ils chauds (crèmes, ocres) ou froids (bleu-gris, ardoises) ?
- Sensation générale : Synthétisez en 1-2 phrases riches qui capturent l'ambiance.
Recherchez ces signaux dans le code source :
| Emplacement Source | Ce qu'il Vous Dit |
|---|---|
background-color racine ou Tailwind bg-* sur les layouts | Clarté/obscurité générale |
| Échelle d'espacement dans la config Tailwind ou les variables CSS | Philosophie des espaces blancs |
| Nombre de composants vs. padding des wrappers | Densité |
Nommage de propriétés personnalisées (--warm-* vs --cool-*) | Intention de température des couleurs |
| Commentaires dans les fichiers thème | Intention de design dans les mots du développeur |
2. Palette de Couleurs & Rôles
Extrayez chaque couleur unique du codebase et attribuez-lui un rôle fonctionnel. Cherchez dans toutes les couches :
Où trouver les couleurs :
| Couche | Que Chercher |
|---|---|
| Propriétés personnalisées CSS | --color-*, --primary, --bg-* |
| Configuration Tailwind | theme.extend.colors |
| Fichiers thème/tokens | Objets couleur, palettes |
| Styles des composants | background-color, color, border-color |
| Styles en ligne / scopes | Classes bg-*, text-* dans les templates |
| Objets thème CSS-in-JS | Clés colors, palette |
Comment organiser : Groupez les couleurs par fonction, pas par teinte :
- Base Principale — Couleurs d'arrière-plan et de surface
- Accent & Interactif — Boutons d'appel à l'action, états actifs, liens
- Typographie & Hiérarchie de Texte — Texte primaire, secondaire, tertiaire
- États Fonctionnels — Succès, erreur, avertissement, information
Pour chaque couleur, créez un nom descriptif qui évoque le caractère de la couleur plutôt que sa valeur hexadécimale brute :
- ❌
#294056→ "Bleu" - ✅
#294056→ "Bleu-Navy Terne et Mute" — Appel à l'action principal, navigation active
La déduplication est importante. Les codebases ont souvent des couleurs quasi-dupliquées (ex : #333 et #2C2C2C). Consolidez-les sous un seul nom qui représente le mieux la couleur prévue.
3. Règles Typographiques
Extrayez le système typographique complet :
Familles de polices :
- Vérifiez CSS
font-family, TailwindfontFamily, les polices Google Fonts, ou les déclarations locales@font-face. - Notez le caractère de chaque police : géométrique vs humaniste, serif vs sans, l'impression qu'elle évoque.
Échelle typographique (hiérarchie) :
- Trouvez chaque niveau de titre (H1-H6) et le corps de texte, en notant :
font-size(en rem ou px)font-weight(valeur numérique + nom descriptif)letter-spacing(et pourquoi — élégance ? compacité ?)line-height(généreux pour la lisibilité ? serré pour l'affichage ?)
- Cartographiez l'utilisation des composants : Quel niveau de titre utilisent les fiches produit ? Qu'en est-il des sections "hero" ?
Principes d'espacement :
- Comment l'espacement du texte se rapporte-t-il à l'échelle d'espacement globale ?
- Les motifs d'interlettrage sur les titres vs le corps
- Philosophie de hauteur de ligne (généreux/détendu pour le corps, plus serré pour l'affichage)
4. Styles des Composants
Analysez les 4-5 primitives d'interface utilisateur les plus importantes :
Boutons :
- Rayon de bord (et ce qu'il communique — ludique ? professionnel ? minimal ?)
- Schéma de couleurs pour les variantes primaire, secondaire et fantôme
- États survol/focus/actif et durée de la transition
- Ratios de padding (horizontal vs vertical)
Cartes / Conteneurs :
- Rayon de bord (souvent différent des boutons — légèrement plus arrondi)
- Stratégie d'ombres : plat, ombres subtiles au survol, ou toujours en relief ?
- Traitement des bordures : bordures filaires, accents colorés, ou aucune ?
- Padding interne (généreux ou compact ?)
- Traitement des images dans les cartes (pleine largeur, avec marge, arrondie ?)
Navigation :
- Modèle de disposition (barre horizontale, barre latérale verticale, tiroir)
- Traitement typographique (majuscules, interlettrage, graisse)
- Indicateurs d'état actif/survol (soulignement, couleur, arrière-plan)
- Comportement mobile (hamburger, menu en bas, tiroir)
Champs de saisie & Formulaires :
- Style de bordure et comportement à l'état focus
- Cohérence du rayon de bord avec les boutons
- Taille du padding et des cibles tactiles
Composants Spécifiques au Domaine :
- Identifiez 1-2 composants uniques à ce projet (ex : fiches produit, widgets de tableau de bord, bulles de chat) et décrivez leurs motifs de style.
5. Principes de Mise en Page
Extrayez le système structurel :
Grille & Structure :
- Largeur maximale du contenu (à partir de
max-widthsur les conteneurs) - Système de colonnes (modèles CSS Grid, Flexbox, points de rupture définis)
- Points de rupture réactifs (à partir des media queries ou de la config Tailwind)
Stratégie des Espaces Blancs :
- Unité d'espacement de base (grille de 8px ? 4px ? personnalisé ?)
- Marges de section (combien d'espace entre les sections principales)
- Padding de bord (marges de page à différents points de rupture)
Alignement & Équilibre Visuel :
- Modèles d'alignement du texte (hero centrés, corps aligné à gauche)
- Ratios image-texte
- Distribution du poids visuel
Comportement Réactif :
- Mobile-first ou desktop-first ?
- Comment les grilles s'effondrent-elles ? Échelle de padding ?
- Taille des cibles tactiles
6. Notes de Génération pour Stitch
Synthétisez l'extraction en instructions actionnables pour Stitch :
- Langage d'ambiance : Traduisez l'ambiance en descripteurs naturels
- Références de couleurs : Listez les couleurs par nom descriptif + hex
- Prompts de composants : Écrivez 2-3 exemples de prompts qui recréeraient les composants clés dans Stitch
- Guidance d'itération : Conseils pour affiner les écrans dans ce système de design
Phase 3 : Écrire le DESIGN.md
Assemblez tout dans le format standard DESIGN.md. Placez-le dans .stitch/DESIGN.md dans le répertoire du projet (créez le répertoire .stitch/ s'il n'existe pas).
[!IMPORTANT] Vous DEVEZ inclure le bloc frontmatter YAML en haut du fichier avec les correspondances
nameetcolors, exactement comme indiqué dans l'exemple à examples/DESIGN.md. Ces données structurées sont nécessaires pour que d'autres compétences puissent parser le système de design.Ne pas inclure ce bloc YAML avec au moins les tokens de couleur principaux est un échec dans l'utilisation correcte de cette compétence.
Utilisez le format de l'exemple à examples/DESIGN.md comme modèle. Le fichier doit commencer par le bloc YAML, suivi des sections markdown :
# Design System: [Nom du Projet]
**Project ID:** [Si connu, sinon omis]
## 1. Thème Visuel & Atmosphère
[Description riche en 2 paragraphes de l'ambiance, de la philosophie et des caractéristiques clés]
## 2. Palette de Couleurs & Rôles
### Base Principale
### Accent & Interactif
### Typographie & Hiérarchie de Texte
### États Fonctionnels
## 3. Règles Typographiques
### Hiérarchie & Graisses
### Principes d'Espacement
## 4. Styles des Composants
### Boutons
### Cartes & [Conteneurs Spécifiques au Domaine]
### Navigation
### Champs de saisie & Formulaires
### [Composants Spécifiques au Domaine]
## 5. Principes de Mise en Page
### Grille & Structure
### Stratégie des Espaces Blancs
### Alignement & Équilibre Visuel
### Comportement Réactif & Tactile
## 6. Notes du Système de Design pour la Génération Stitch
### Langage à Utiliser
### Références de Couleurs
### Prompts de Composants
### Itération Incrémentale
Phase 4 : Intégration (Optionnelle)
Si l'utilisateur veut pousser le système de design dans Stitch :
- Passez le relais à la compétence
manage-design-systempour les appels MCP de création/mise à jour - Le DESIGN.md que vous avez écrit est l'entrée — la compétence manage-design-system gère l'intégration avec l'API Stitch
Si l'utilisateur veut juste le document, vous avez terminé après la Phase 3.
Checklist Qualité
Avant de livrer le DESIGN.md, vérifiez :
- Chaque couleur a un nom descriptif, un code hexadécimal et un rôle fonctionnel
- La typographie inclut la famille de police, la description du caractère et la hiérarchie complète
- Les styles de composants décrivent la forme, la couleur, les états et les transitions
- La mise en page inclut la largeur maximale, la grille, les points de rupture et la stratégie d'espacement
- Les notes de génération Stitch utilisent un langage naturel, pas une syntaxe CSS
- La section d'ambiance se lit comme un texte éditorial, pas des docs techniques
- Les couleurs quasi-dupliquées sont consolidées
- Le document capture l'intention derrière le style, pas seulement les valeurs brutes
Conseils pour une Meilleure Extraction
- Lisez les commentaires et les messages de commit. Les développeurs documentent souvent l'intention de design dans les commentaires de code (
/* section hero — aérée */) et les messages de commit. C'est de l'or pour comprendre le pourquoi. - Vérifiez les bibliothèques de tokens de design. Si le projet utilise
style-dictionary,@tokens-studio, ou similaire, ces fichiers sont la source la plus fiable des valeurs de design. - Les fichiers thème sont un signal plus fort que les styles de composants. Un
theme.tsqui définit une palette vous renseigne sur le système de design prévu ; les styles en ligne éparpillés dans les composants indiquent ce qui a vraiment été livré. Les deux comptent, mais commencez par le thème. - La configuration Tailwind est un système de design. Si un projet a un
tailwind.config.jspersonnalisé, c'est le système de design — extrayez-en d'abord, puis vérifiez les composants pour les surcharges. - Les propriétés personnalisées CSS sont intentionnelles. Si un développeur a défini
--brand-primary, il vous indique que c'est un token de design. Respectez cela.