/balise-design-system

name: balise-design-system
description: "Architecturer, auditer, construire, intégrer et faire évoluer un design system robuste de Figma au code. Utiliser pour cadrer un système partagé, structurer style guides et variables, design tokens primitifs/sémantiques/composants, aliases, thèmes et modes, rampes de couleur, échelles typographiques, composants et patterns; organiser Figma-to-code, DTCG, Style Dictionary, packages multi-plateformes, Tailwind ou shadcn; auditer ou consolider l’architecture UI partagée d’un SaaS, dashboard, produit multi-tenant ou base existante; guider consommation, documentation, gouvernance, versionnage et migration. Déclencheurs : design system, design tokens, style guide, Figma variables, component library, UI kit, theming, dark mode, multi-marque, multi-tenant design system, SaaS design system, Tailwind theme architecture, semantic tokens, DTCG, Style Dictionary, design-to-code."

Design System

Concevoir le système comme un produit partagé : décisions, composants, documentation, distribution et gouvernance. Ne jamais réduire la réponse à une palette, un fichier de variables ou une bibliothèque isolée.

Choisir le workflow

Qualifier la demande avant d’agir :

| Demande | Point de départ | Sortie principale | |---|---|---| | Définir une approche | contexte, finalité, consommateurs | brief, options, architecture, pilote | | Auditer l’existant | code, design, docs, usages | inventaire, divergences, dette, priorités | | Créer ou migrer des tokens | produits, modes, plateformes | taxonomie, source, mappings, pipeline | | Construire les fondations | usages et contraintes réels | rampes, rôles, échelles, validations | | Structurer Figma et relier au code | styles, variables, collections, composants | mapping, autorités, preuves de synchronisation | | Consolider un SaaS | navigation, données, formulaires, tenants | fondations, patterns, états, densité, thèmes | | Adapter Tailwind ou une base UI | version, conventions, dette, API existante | stratégie extend/override/replace, pont sémantique | | Spécifier un composant/pattern | problème, contexte, états | contrat, API, comportement, preuves | | Guider la consommation | rôles et points de friction | golden path, extension, contribution, upgrade | | Organiser la gouvernance | équipe, capacité, risques | ownership, maturité, release, métriques |

Lire seulement les références nécessaires :

• Stratégie, périmètre et modèle d’organisation : [references/strategy-and-scope.md](references/strategy-and-scope.md)
• Audits, inventaires et sélection du pilote : [references/audits-and-pilots.md](references/audits-and-pilots.md)
• Architecture DTCG, couches, alias, thèmes et modes : [references/token-architecture.md](references/token-architecture.md)
• Nommage et autorités design/code/docs : [references/naming-and-source-authority.md](references/naming-and-source-authority.md)
• Couleur, typographie, espace et autres fondations : [references/color-and-typography.md](references/color-and-typography.md)
• Primitives UI, composants, patterns et états : [references/components-and-patterns.md](references/components-and-patterns.md)
• Parcours consommateur, onboarding et documentation : [references/consumption-and-learning.md](references/consumption-and-learning.md)
• Gouvernance, maturité, contribution et mesure : [references/governance-and-maturity.md](references/governance-and-maturity.md)
• Transformations, packages, tests, releases et migrations : [references/implementation-pipelines.md](references/implementation-pipelines.md)
• Style Dictionary, cycle de compilation et critères d’adoption : [references/style-dictionary.md](references/style-dictionary.md)
• Variables, styles, bibliothèques et passage Figma → code : [references/figma-to-code.md](references/figma-to-code.md)
• Fondations et patterns structurels pour produits SaaS : [references/saas-structures.md](references/saas-structures.md)
• Adoption de Tailwind, shadcn et autres bases UI : [references/framework-adoption.md](references/framework-adoption.md)
• Fiches, matrices et contrats de livraison : [references/deliverable-templates.md](references/deliverable-templates.md)

Workflow cœur

1. Inspecter le réel

Inspecter avant de recommander :

• produits, surfaces, marques, thèmes, modes, langues et plateformes ;
• équipes productrices, mainteneurs, consommateurs et sponsors ;
• styles, variables, tokens, composants, patterns et documentation existants ;
• frameworks, build, packages, versions, compatibilité et contraintes de sécurité ;
• accessibilité, performance, legacy, white-label, natif et calendrier ;
• répétitions, forks, valeurs brutes, divergences et contournements.

Utiliser les scripts fournis lorsqu’ils correspondent au format réel :

python3 <skill-dir>/scripts/validate_dtcg.py path/to/tokens.json
python3 <skill-dir>/scripts/audit_token_usage.py src --manifest path/to/generated-tokens.css

Résoudre `<skill-dir>` depuis le chemin absolu du `SKILL.md` sélectionné, jamais depuis le cwd du projet consommateur. Ne pas présenter ces contrôles ciblés comme une validation complète du schéma DTCG, ni comme une preuve visuelle, comportementale ou d’accessibilité.

2. Cadrer le résultat

Énoncer : contexte, objectif, non-objectifs, publics, périmètre, principes, contraintes, workstreams et critères d’acceptation observables.

Situer le système sur trois axes :

• strict ↔ souple ;
• modulaire ↔ intégré ;
• centralisé ↔ distribué.

Pouvoir conclure qu’un système complet n’est pas justifié. Préférer alors des conventions légères, quelques fondations ou un kit local maintenable.

3. Modéliser les décisions

Choisir uniquement les couches utiles :

1. valeurs sources ou mesures ; 2. primitives/références/options ; 3. sémantiques/décisions ; 4. composants/patterns si une décision doit varier indépendamment ; 5. contextes produit seulement s’ils expriment une responsabilité légitime.

Traiter marque, thème clair/sombre, contraste, densité,