Créer des règles de système de design

Présentation générale

Cette compétence vous aide à générer des règles de système de design personnalisées adaptées aux besoins spécifiques de votre projet. Ces règles guident les agents de codage IA pour produire du code cohérent et de haute qualité lors de l'implémentation de designs Figma, en veillant à ce que les conventions de votre équipe, les modèles de composants et les décisions architecturales soient suivis automatiquement.

Fichiers de règles supportés

Qu'est-ce que les règles de système de design ?

Les règles de système de design sont des instructions au niveau du projet qui codifient la « connaissance implicite » de votre base de code - le type d'expertise que les développeurs expérimentés connaissent et transmettraient aux nouveaux membres de l'équipe :

• Quels primitifs de mise en page et composants utiliser
• Où doivent se trouver les fichiers de composants
• Comment les composants doivent être nommés et structurés
• Ce qui ne doit jamais être codé en dur
• Comment gérer les tokens de design et le style
• Modèles architecturaux spécifiques au projet

Une fois définis, ces règles réduisent considérablement les invites répétitives et garantissent une sortie cohérente dans toutes les tâches d'implémentation Figma.

Prérequis

• Le serveur Figma MCP doit être connecté et accessible
• Accès à la base de code du projet pour l'analyse
• Compréhension des conventions de composants de votre équipe (ou volonté de les établir)

Quand utiliser cette compétence

Utilisez cette compétence quand :

• Vous démarrez un nouveau projet qui utilisera des designs Figma
• Vous intégrez un agent de codage IA dans un projet existant avec des modèles établis
• Vous standardisez les workflows Figma vers code dans votre équipe
• Vous mettez à jour ou affinez les conventions de système de design existantes
• Les utilisateurs demandent explicitement : « créer des règles de système de design », « configurer les directives Figma », « personnaliser les règles pour mon projet »

Workflow requis

Suivez ces étapes dans l'ordre. Ne sautez pas d'étapes.

Étape 1 : Exécuter l'outil de création des règles de système de design

Appelez l'outil create_design_system_rules du serveur Figma MCP pour obtenir le prompt fondateur et le modèle.

Paramètres :

• clientLanguages : Liste séparée par des virgules des langages utilisés dans le projet (ex. « typescript,javascript », « python », « javascript »)
• clientFrameworks : Framework utilisé (ex. « react », « vue », « svelte », « angular », « unknown »)

Cet outil retourne des conseils et un modèle pour créer des règles de système de design.

Structurez vos règles de système de design en suivant le format de modèle fourni dans la réponse de l'outil.

Étape 2 : Analyser la base de code

Avant de finaliser les règles, analysez le projet pour comprendre les modèles existants :

Organisation des composants :

• Où se trouvent les composants UI ? (ex. src/components/, app/ui/, lib/components/)
• Y a-t-il un répertoire dédié au système de design ?
• Comment les composants sont-ils organisés ? (par fonctionnalité, par type, structure plate)

Approche du style :

• Quel framework CSS ou approche est utilisé ? (Tailwind, CSS Modules, styled-components, etc.)
• Où les tokens de design sont-ils définis ? (variables CSS, fichiers de thème, fichiers de config)
• Existet-il des tokens de couleur, typographie ou espacement ?

Modèles de composants :

• Quelles conventions de nommage sont utilisées ? (PascalCase, kebab-case, préfixes)
• Comment les props des composants sont-ils typiquement structurés ?
• Y a-t-il des modèles de composition courants ?

Décisions architecturales :

• Comment la gestion d'état est-elle gérée ?
• Quel système de routage est utilisé ?
• Y a-t-il des modèles d'import spécifiques ou des alias de chemins ?

Étape 3 : Générer les règles spécifiques au projet

En fonction de votre analyse de codebase, créez un ensemble complet de règles. Incluez :

Règles générales des composants

- IMPORTANT : Toujours utiliser les composants de `[VOTRE_CHEMIN]` quand possible
- Placer les nouveaux composants UI dans `[RÉPERTOIRE_COMPOSANTS]`
- Suivre `[CONVENTION_NOMMAGE]` pour les noms des composants
- Les composants doivent exporter comme `[MODÈLE_EXPORT]`

Règles de style

- Utiliser `[FRAMEWORK_CSS/APPROCHE]` pour le style
- Les tokens de design sont définis dans `[LOCALISATION_TOKENS]`
- IMPORTANT : Ne jamais coder les couleurs en dur - toujours utiliser les tokens de `[FICHIER_TOKENS]`
- Les valeurs d'espacement doivent utiliser l'échelle `[SYSTÈME_ESPACEMENT]`
- La typographie suit l'échelle définie dans `[LOCALISATION_TYPOGRAPHIE]`

Règles d'intégration Figma MCP

## Règles d'intégration Figma MCP

Ces règles définissent comment traduire les entrées Figma en code pour ce projet et doivent être suivies pour chaque modification basée sur Figma.

### Flux requis (ne pas sauter)

1. Exécuter get_design_context en premier pour récupérer la représentation structurée du/des nœud(s) exact(s)
2. Si la réponse est trop grande ou tronquée, exécuter get_metadata pour obtenir la carte des nœuds de haut niveau, puis re-récupérer seulement le(s) nœud(s) requis avec get_design_context
3. Exécuter get_screenshot pour une référence visuelle de la variante du nœud implémentée
4. Seulement après avoir à la fois get_design_context et get_screenshot, télécharger les ressources nécessaires et commencer l'implémentation
5. Traduire la sortie (généralement React + Tailwind) dans les conventions, styles et framework de ce projet
6. Valider par rapport à Figma pour une correspondance 1:1 look et comportement avant de marquer comme terminé

### Règles d'implémentation

- Traiter la sortie Figma MCP (React + Tailwind) comme une représentation du design et du comportement, non comme un style de code final
- Remplacer les classes d'utilitaires Tailwind par `[VOTRE_APPROCHE_STYLE]` le cas échéant
- Réutiliser les composants existants de `[CHEMIN_COMPOSANTS]` au lieu de dupliquer la fonctionnalité
- Utiliser le système de couleurs, l'échelle typographique et les tokens d'espacement du projet de manière cohérente
- Respecter les modèles de routage, gestion d'état et récupération de données existants
- Viser la parité visuelle 1:1 avec le design Figma
- Valider l'UI finale par rapport à la capture d'écran Figma pour le look et le comportement

Règles de gestion des ressources

## Gestion des ressources

- Le serveur Figma MCP fournit un endpoint de ressources qui peut servir des ressources image et SVG
- IMPORTANT : Si le serveur Figma MCP retourne une source localhost pour une image ou SVG, utiliser cette source directement
- IMPORTANT : NE PAS importer/ajouter de nouveaux packages d'icônes - toutes les ressources doivent être dans la charge Figma
- IMPORTANT : NE PAS utiliser ou créer de placeholders si une source localhost est fournie
- Stocker les ressources téléchargées dans `[RÉPERTOIRE_RESSOURCES]`

Conventions spécifiques au projet

## Conventions spécifiques au projet

- [Ajouter tout modèle architectural unique]
- [Ajouter toute exigence d'import spéciale]
- [Ajouter toute exigence de test]
- [Ajouter tout standard d'accessibilité]
- [Ajouter toute considération de performance]

Étape 4 : Enregistrer les règles dans le fichier de règles approprié

Détectez quel agent de codage IA l'utilisateur utilise et enregistrez les règles générées dans le fichier correspondant :

Si vous ne savez pas quel agent l'utilisateur utilise, vérifiez les fichiers de règles existants dans le projet ou demandez à l'utilisateur.

Pour Cursor, envelopper les règles avec un frontmatter YAML :

---
description: Règles pour implémenter des designs Figma en utilisant le serveur Figma MCP. Couvre l'organisation des composants, les conventions de style, les tokens de design, la gestion des ressources et le workflow Figma-vers-code requis.
globs: "src/components/**"
alwaysApply: false
---

[Règles générées ici]

Personnaliser le modèle globs pour correspondre aux répertoires où le code dérivé de Figma vivra dans le projet (ex. "src/**/*.tsx" ou ["src/components/**", "src/pages/**"]).

Une fois enregistrées, les règles seront automatiquement chargées par l'agent et appliquées à toutes les tâches d'implémentation Figma.

Étape 5 : Valider et itérer

Après la création des règles :

1. Tester avec une implémentation simple de composant Figma
2. Vérifier que l'agent suit correctement les règles
3. Affiner toute règle qui ne fonctionne pas comme prévu
4. Partager avec les membres de l'équipe pour retours
5. Mettre à jour les règles à mesure que le projet évolue

Catégories de règles et exemples

Règles essentielles (toujours inclure)

Découverte des composants :

- Les composants UI se trouvent dans `src/components/ui/`
- Les composants de fonctionnalité sont dans `src/components/features/`
- Les primitifs de mise en page sont dans `src/components/layout/`

Utilisation des tokens de design :

- Les couleurs sont définies comme variables CSS dans `src/styles/tokens.css`
- Ne jamais coder les valeurs hexadécimales en dur - utiliser les tokens `var(--color-*)`
- L'espacement utilise l'échelle de base 4px : `--space-1` (4px), `--space-2` (8px), etc.

Approche du style :

- Utiliser les classes d'utilitaires Tailwind pour le style
- Les styles personnalisés vont dans les modules CSS au niveau des composants
- La personnalisation du thème est dans `tailwind.config.js`

Règles recommandées (très utiles)

Modèles de composants :

- Tous les composants doivent accepter une prop `className` pour la composition
- Les props de variante doivent utiliser les types union : `variant: 'primary' | 'secondary'`
- Les composants d'icône doivent accepter les props `size` et `color`

Conventions d'import :

- Utiliser les alias de chemins : `@/components`, `@/styles`, `@/utils`
- Grouper les imports : React, tiers, internes, types
- Pas d'imports relatifs au-delà du répertoire parent

Qualité du code :

- Ajouter des commentaires JSDoc pour les composants exportés
- Inclure PropTypes ou les types TypeScript pour tous les props
- Extraire les nombres magiques en constantes nommées

Règles facultatives (spécifiques au projet)

Accessibilité :

- Tous les éléments interactifs doivent avoir des aria-labels
- Le contraste des couleurs doit respecter les standards WCAG AA
- La navigation au clavier est requise pour toutes les interactions

Performance :

- Charger les images en lazy load avec le composant `Image` de `@/components/Image`
- Utiliser React.memo pour les composants qui reçoivent des props complexes
- Les icônes doivent être des composants SVG, pas des polices d'icônes

Tests :

- Inclure les tests unitaires pour les nouveaux composants dans le répertoire `__tests__/`
- Utiliser les requêtes Testing Library (getByRole, getByLabelText)
- Tester tous les états interactifs et variantes

Exemples

Exemple 1 : Projet React + Tailwind

L'utilisateur dit : « Créer des règles de système de design pour mon projet React »

Actions :

1. Exécuter create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="react")
2. Analyser la structure de la base de code
3. Générer les règles :

# Règles d'intégration Figma MCP

## Organisation des composants

- Les composants UI sont dans `src/components/ui/`
- Les composants de page sont dans `src/app/`
- Utiliser Tailwind pour le style

## Flux d'implémentation Figma

1. Exécuter get_design_context pour le nœud
2. Exécuter get_screenshot pour une référence visuelle
3. Mapper les couleurs Figma aux couleurs Tailwind définies dans `tailwind.config.js`
4. Réutiliser les composants de `src/components/ui/` quand possible
5. Valider par rapport à la capture d'écran avant la fin

## Règles de style

- IMPORTANT : Utiliser les classes d'utilitaires Tailwind, pas les styles inline
- Les couleurs sont définies dans `tailwind.config.js` theme.colors
- L'espacement utilise l'échelle par défaut de Tailwind
- Les composants personnalisés vont dans `src/components/ui/`

## Règles des ressources

- IMPORTANT : Utiliser les sources localhost du serveur Figma MCP directement
- Stocker les ressources statiques dans `public/assets/`
- NE PAS installer de nouvelles bibliothèques d'icônes

4. Enregistrer dans le fichier de règles approprié pour l'agent de l'utilisateur
5. Tester avec une implémentation simple de bouton

Résultat : L'agent suit maintenant régulièrement les conventions du projet lors de l'implémentation des designs Figma.

Exemple 2 : Projet Vue + CSS personnalisé

L'utilisateur dit : « Configurer les règles Figma pour mon app Vue »

Actions :

1. Exécuter create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="vue")
2. Découvrir que le projet utilise les modules CSS et un système de tokens de design personnalisé
3. Générer les règles :

# Règles d'intégration Figma MCP

## Organisation des composants

- Les composants sont dans `src/components/`
- Les composables sont dans `src/composables/`
- Structure Vue SFC : <script setup>, <template>, <style scoped>

## Tokens de design

- IMPORTANT : Toutes les couleurs définies dans `src/styles/tokens.css` comme variables CSS
- Utiliser `var(--color-primary)`, `var(--color-secondary)`, etc.
- Espacement : `var(--space-xs)` jusqu'à `var(--space-xl)`
- Typographie : `var(--text-sm)` jusqu'à `var(--text-2xl)`

## Flux d'implémentation Figma

1. Exécuter get_design_context et get_screenshot
2. Traduire la sortie React vers l'API de composition Vue 3
3. Mapper les couleurs Figma aux variables CSS dans `src/styles/tokens.css`
4. Utiliser les modules CSS pour les styles de composants
5. Vérifier les composants existants dans `src/components/` avant d'en créer de nouveaux

## Règles de style

- Utiliser les modules CSS (fichiers `.module.css`)
- IMPORTANT : Référencer les tokens de design, ne jamais coder les valeurs en dur
- Styles scoped avec modules CSS

4. Enregistrer dans le fichier de règles approprié pour l'agent de l'utilisateur
5. Valider avec un composant de carte

Résultat : L'agent traduit maintenant correctement les designs Figma en composants Vue en utilisant le système de tokens de design du projet.

Exemple 3 : Équipe de système de design

L'utilisateur dit : « Générer des règles pour notre bibliothèque de système de design »

Actions :

1. Exécuter create_design_system_rules(clientLanguages="typescript", clientFrameworks="react")
2. Analyser la structure du monorepo avec le package de système de design
3. Générer les règles complètes :

# Règles de système de design

## Structure du repository

- Composants du système de design : `packages/design-system/src/components/`
- Documentation : `packages/docs/`
- Tokens de design : `packages/tokens/src/`

## Développement des composants

- IMPORTANT : Tous les composants doivent être dans `packages/design-system/src/components/`
- Structure des fichiers de composants : `ComponentName/index.tsx`, `ComponentName.stories.tsx`, `ComponentName.test.tsx`
- Exporter tous les composants de `packages/design-system/src/index.ts`

## Tokens de design

- Couleurs : `packages/tokens/src/colors.ts`
- Typographie : `packages/tokens/src/typography.ts`
- Espacement : `packages/tokens/src/spacing.ts`
- IMPORTANT : Ne jamais coder les valeurs en dur - importer du package de tokens

## Exigences de documentation

- Ajouter une histoire Storybook pour chaque composant
- Inclure la JSDoc avec @example
- Documenter tous les props avec des descriptions
- Ajouter des notes d'accessibilité

## Intégration Figma

1. Récupérer le contexte de design et la capture d'écran de Figma
2. Mapper les tokens Figma aux tokens du système de design
3. Créer ou étendre le composant dans le package du système de design
4. Ajouter les histoires Storybook montrant toutes les variantes
5. Valider par rapport à la capture d'écran Figma
6. Mettre à jour la documentation

4. Enregistrer dans le fichier de règles approprié et partager avec l'équipe
5. Ajouter à la documentation de l'équipe

Résultat : Toute l'équipe suit des modèles cohérents lors de l'ajout de composants de Figma au système de design.

Bonnes pratiques

Commencer simple, itérer

N'essayez pas de capturer toutes les règles dès le départ. Commencez par les conventions les plus importantes et ajoutez des règles au fur et à mesure que vous rencontrez des incohérences.

Être spécifique

Au lieu de : « Utiliser le système de design » Écrire : « Toujours utiliser les composants Button de src/components/ui/Button.tsx avec la prop variante ('primary' | 'secondary' | 'ghost') »

Rendre les règles actionnables

Chaque règle doit indiquer à l'agent exactement quoi faire, pas seulement quoi éviter.

Bon : « Les couleurs sont définies dans src/theme/colors.ts - importer et utiliser ces constantes » Mauvais : « Ne pas coder les couleurs en dur »

Utiliser IMPORTANT pour les règles critiques

Préfixer les règles qui ne doivent jamais être violées avec « IMPORTANT : » pour s'assurer que l'agent les priorise.

- IMPORTANT : Ne jamais exposer les clés API côté client
- IMPORTANT : Toujours assainir les entrées utilisateur avant de les rendre

Documenter le pourquoi

Quand les règles semblent arbitraires, expliquer le raisonnement :

- Placer toute la récupération de données dans les composants serveur (réduit la taille du bundle client et améliore les performances)
- Utiliser les imports absolus avec l'alias `@/` (facilite la refactorisation et évite les chemins relatifs cassés)

Problèmes courants et solutions

Problème : L'agent ne suit pas les règles

Cause : Les règles peuvent être trop vagues ou ne pas être correctement chargées par l'agent. Solution :

• Rendre les règles plus spécifiques et actionnables
• Vérifier que les règles sont enregistrées dans le fichier de configuration correct
• Redémarrer votre agent ou IDE pour recharger les règles
• Ajouter le préfixe « IMPORTANT : » aux règles critiques

Problème : Les règles entrent en conflit les unes avec les autres

Cause : Règles contradictoires ou chevauchantes. Solution :

• Examiner toutes les règles pour les conflits
• Établir une hiérarchie de priorités claires
• Supprimer les règles redondantes
• Consolider les règles connexes en des déclarations claires et uniques

Problème : Trop de règles augmentent la latence

Cause : Les règles excessives augmentent la taille du contexte et le temps de traitement. Solution :

• Se concentrer sur les 20 % de règles qui résolvent 80 % des problèmes de cohérence
• Supprimer les règles trop spécifiques qui s'appliquent rarement
• Combiner les règles connexes
• Utiliser la divulgation progressive (règles basiques d'abord, règles avancées dans les fichiers liés)

Problème : Les règles deviennent obsolètes au fur et à mesure que le projet évolue

Cause : La base de code change mais les règles ne suivent pas. Solution :

• Planifier des examens de règles périodiques (mensuels ou trimestriels)
• Mettre à jour les règles quand les décisions architecturales changent
• Versionnez vos fichiers de règles dans le contrôle de version
• Documenter les modifications de règles dans les messages de commit

Comprendre les règles du système de design

Les règles du système de design transforment la façon dont les agents de codage IA fonctionnent avec vos designs Figma :

Avant les règles :

• L'agent fait des hypothèses sur la structure des composants
• Approches de style incohérentes dans les implémentations
• Valeurs codées en dur qui ne correspondent pas aux tokens de design
• Composants créés dans des emplacements aléatoires
• Explications répétitives des conventions du projet

Après les règles :

• L'agent suit automatiquement vos conventions
• Structure et style des composants cohérents
• Utilisation correcte des tokens de design dès le départ
• Composants organisés correctement
• Zéro invites répétitives

Le temps investi dans la création de bonnes règles se rentabilise exponentiellement dans chaque tâche d'implémentation Figma.

Ressources supplémentaires

• Documentation du serveur Figma MCP
• Variables et tokens de design Figma