FReptar0/design-guard

Génère un fichier DESIGN.md complet pour un projet web en utilisant Google Stitch.

Instructions

0. Vérification de découverte (À EXÉCUTER avant toute autre chose) :
   • Vérifiez si le répertoire .dg-research/ existe et contient des fichiers JSON.
   • SI .dg-research/ n'existe PAS ET que l'utilisateur a mentionné un nom d'entreprise, société, marque, café, restaurant, magasin ou entité réelle spécifique :
     • ARRÊTEZ-VOUS. Dites à l'utilisateur : « Je recommande d'exécuter /dg-discover d'abord pour rechercher [nom de l'entreprise]. Cela produit un DESIGN.md fondé sur des données réelles du marché et des concurrents, plutôt que sur des valeurs par défaut de l'IA. Souhaitez-vous que j'exécute /dg-discover à la place ? »
     • Ne poursuivez avec /dg-design que si l'utilisateur dit explicitement de sauter la recherche.
   • SI .dg-research/ existe avec des fichiers JSON : Lisez .dg-research/latest.json pour obtenir le brief métier, l'analyse concurrentielle et les couleurs de la marque. Ces données de recherche sont votre source PRINCIPALE pour le contexte métier — utilisez-les plutôt que tout contexte de projet provenant de CLAUDE.md. Passez à l'étape 1.
   • SI la demande de l'utilisateur est générique (aucune entreprise spécifique mentionnée, par exemple « crée un site portfolio » ou « crée un tableau de bord SaaS ») : passez directement à l'étape 1. La recherche est réservée aux vraies entreprises, pas aux projets génériques.

Isolation de contexte (CRITIQUE — à lire avant de générer)

Lors de la génération d'un DESIGN.md, distinguez deux contextes :

1. Projet hôte — le code source dans lequel vous opérez (Design Guard). CLAUDE.md décrit CE projet. Son modèle économique, ses fonctionnalités, ses commandes CLI, ses décomptes de tests et son architecture technique concernent Design Guard, PAS l'entreprise cible de l'utilisateur.

2. Entreprise cible — l'entreprise pour laquelle l'utilisateur souhaite un DESIGN.md. Cela provient de :

   • Le brief de marque fourni par l'utilisateur (Étape 1)
   • Les données de recherche dans .dg-research/latest.json (si disponibles via /dg-discover — c'est votre source PRINCIPALE)
   • Les résultats de WebSearch/WebFetch concernant l'entreprise cible

Règles :

• SI l'entreprise cible est DIFFÉRENTE de Design Guard :

  • N'utilisez PAS de descriptions métier, listes de fonctionnalités, statistiques ni détails techniques provenant de CLAUDE.md
  • Ne référencez PAS les commandes CLI, les décomptes de tests, TypeScript, Node.js, MCP ou Stitch comme caractéristiques de l'entreprise cible
  • Ne décrivez PAS la cible comme « open source », « intelligence de design » ou toute autre phrase du Project Overview de CLAUDE.md
  • Chaque fait métier dans le DESIGN.md doit provenir du brief de l'utilisateur ou des données de recherche
  • Si un DESIGN.md existe déjà à la racine du projet, ne copiez PAS ses couleurs, polices ou contexte métier dans le nouveau — générez à partir du brief et de la recherche

• SI l'entreprise cible EST Design Guard elle-même :

  • CLAUDE.md est une source valide de contexte métier — utilisez-le en complément du brief de l'utilisateur

• Suivez TOUJOURS les règles de spécification et de validation en 8 sections de DESIGN.md provenant de CLAUDE.md, quel que soit le contexte métier. Les règles de FORMAT s'appliquent toujours ; le contexte MÉTIER est ce qui est isolé.

1. Si l'utilisateur a fourni un brief de marque comme argument, utilisez-le. Sinon, demandez :

   • Nom de l'entreprise/produit
   • Secteur ou domaine
   • Public cible
   • Direction esthétique (par exemple, « corporate haut de gamme », « startup ludique », « SaaS minimaliste »)

2. Générez un DESIGN.md avec exactement ces 8 sections :

   1. Thème visuel et atmosphère — 2-3 phrases évocatrices décrivant l'esthétique globale. Utilisez des adjectifs et références précis, pas de termes génériques.
   2. Palette de couleurs et rôles — Tableau Markdown avec colonnes : Rôle, Nom, Hex, Utilisation. Minimum 5 rôles (Primaire, Secondaire, Surface, Sur-Surface, Erreur). Toutes les couleurs en valeurs hexadécimales, jamais de descriptions comme « bleu de confiance ». Donnez à chaque couleur un nom descriptif (par exemple, « Bleu Marine » pas seulement « Primaire »).
   3. Typographie — Polices de caractères issues de Google Fonts (évitez Inter, Poppins comme police principale — elles signalent un design généré par IA). Tailles en rem/px, graisses en chiffres (400/600/700), hauteurs de ligne. Incluez les styles titre, corps et mono. Utilisez une paire serif/sans-serif pour le contraste.
   4. Espacement et mise en page — Unité de base (par exemple, 4px), échelle, largeur de contenu maximale, système de grille, points de rupture.
   5. Motifs de composants — Au moins 3 composants (boutons, cartes, champs de saisie, etc.) avec structure et règles de style. Variez les styles de bordure arrondie et d'ombre.
   6. Iconographie — Style (contour/plein/duotone), taille par défaut, bibliothèque source.
   7. Directives d'imagerie — Style de photo, style d'illustration, ratios d'aspect. Soyez précis sur ce que l'imagerie communique.
   8. À faire et à ne pas faire — Au moins 3 de chaque. DOIT inclure ces valeurs par défaut anti-slop :

   À faire

   • Utilisez des mises en page asymétriques ou non standard pour au moins une section de fonctionnalités
   • Variez les tailles de cartes et l'espacement pour créer un rythme visuel
   • Utilisez exclusivement la palette de couleurs spécifiée (pas de couleurs choisies par l'IA)
   • Maintenez un contraste élevé (4,5:1 minimum) pour tout le texte
   • Variez les arrière-plans des sections (alternez entre surfaces claires et sombres)

   À ne pas faire

   • N'utilisez pas Inter, Poppins ou une police sans-serif système comme police principale
   • N'utilisez pas de dégradés violets vers bleus nulle part
   • N'utilisez pas de bordure uniforme (>12px) sur tous les éléments
   • N'utilisez pas de grilles d'icônes standard à trois colonnes comme deuxième section de page
   • Ne centrez pas le texte du corps sur plus de 2 lignes
   • N'utilisez pas d'illustrations génériques de stock (blobs 3D, formes abstraites)

3. Règles de validation :

   • Toutes les couleurs doivent être des valeurs hexadécimales (#RRGGBB)
   • Tailles de police en rem ou px uniquement
   • Au moins 5 rôles de couleur, 3 motifs de composants, 3 À faire et 3 À ne pas faire
   • Restez sous environ 3000 tokens (Stitch le lit comme contexte à chaque génération)

4. Si DESIGN.md existe déjà, demandez avant d'écraser.

5. Écrivez le fichier dans DESIGN.md à la racine du projet.

6. Après l'écriture, vérifiez si un système de design Stitch existe en utilisant mcp__stitch__list_design_systems. Si l'utilisateur a un projet Stitch :

   • Proposez de créer un système de design avec mcp__stitch__create_design_system
   • Ou de mettre à jour un existant avec mcp__stitch__update_design_system
   • Appliquez-le au projet avec mcp__stitch__apply_design_system pour que toutes les générations futures le respectent

7. Étape suivante : Suggérez d'exécuter /dg-generate pour créer le premier écran en utilisant le nouveau système de design.

Référence : Consultez docs/design-md-guide.md pour la spécification complète.