Style Demo Builder

Que fait Style Demo Builder ?

Transformez n'importe quel produit en une belle page d'atterrissage de démonstration qui emprunte le style visuel d'un site de référence — sa palette, sa typographie, ses motifs de mise en page et son mouvement — tout en racontant l'histoire du produit de l'utilisateur.

Règle d'or : clonez le style, jamais le contenu. Le site de référence fournit l'apparence ; le site/produit de l'utilisateur fournit les mots. La sortie ne doit pas reproduire le texte de la référence, et ne doit pas se contenter de reskinner la mise en page existante de l'utilisateur — ce doit être une page fraîche dans le style emprunté.

C'est l'erreur n°1. Copier la palette de la référence mais conserver le squelette des sections du site de l'utilisateur (ses blocs de fonctionnalités numérotés, ses motifs de cartes, son ordre) produit une page qui ressemble encore au site d'origine de l'utilisateur avec de nouvelles couleurs. Recolorer n'est pas restyler. Vous devez emprunter le squelette de mise en page et les composants signatures de la référence, pas seulement ses valeurs hexadécimales. Recherchez toujours la structure du site de l'utilisateur lui-même (Étape 2) afin de savoir de quoi vous devez diverger.

Motifs de mise en page pris en charge (choisir selon la demande) :

• Style unique emprunté — toute la page dans l'apparence d'une seule référence.
• Visite guidée section par section — chaque section emprunte l'identité d'un site différent (ex. hero → projectdiscovery, tarification → linear, CTA → superhuman). Donnez à chaque <section> son propre bloc de thème délimité : fond, accent, type, rayon, et un composant signature. Idéal quand l'utilisateur dit « chaque section son propre thème ». Gardez-les cohérents (p. ex. tous sombres) sauf s'ils veulent du contraste.

Boîte à outils (livrée avec ce skill — utilisez-la, ne la redérivez pas)

Les chemins sont relatifs au répertoire de ce skill. Préférez-les à une écriture manuelle ; ils encodent les pièges ci-dessous pour que vous ne les rencontriez pas à nouveau.

• template/ — un échafaudage constructible Next 14 + GSAP + Lenis avec la couche de mouvement déjà câblée (SmoothScroll, ScrollProgress, Reveal, globals.css tokenisé, un page.tsx de démarrage). Chaque construction commence ici.
• template-html/index.html — les mêmes tokens + couche de mouvement dans un FICHIER autonome (GSAP/Lenis via CDN). À utiliser lorsque l'utilisateur choisit une sortie HTML fichier unique ; pas d'échafaudage ni d'installation.
• scripts/new-demo.sh <dest> — copie le template vers <dest> et exécute npm install.
• scripts/verify.sh <dir> — Étape 5 sous forme de script : refuse de construire tant que next dev tourne, vérifie les types, construit l'export statique, grep out/index.html.
• scripts/extract-style.js — à exécuter dans une page de référence ouverte via l'outil javascript_tool de Chrome pour extraire les polices/couleurs/rayons/échelles réels dans un projet de spécification (Étape 2).
• scripts/shoot.mjs <url> — capture d'écran headless Playwright, pour les sandbox sans affichage/CI uniquement. Localement, faites plutôt une capture d'écran avec les outils Chrome.
• scripts/deploy.sh [dir] [--prod] — expédie le répertoire statique construit (out/, ou le dossier du fichier HTML unique) vers une URL en ligne. Vercel par défaut ; ce ne sont que des fichiers statiques, donc n'importe quel hébergeur fonctionne. Orienté vers l'extérieur — construisez d'abord et confirmez avec l'utilisateur avant --prod.
• scripts/audit.sh <url> — scores Lighthouse (perf/a11y/best-practices/SEO) sur un serveur de développement ou un déploiement.
• references/patterns.md — recettes d'animation + plans de composants signatures, choisis selon l'énergie de la référence.

Étape 1 — Interroger l'utilisateur (faites ceci en premier)

Utilisez l'outil AskUserQuestion. Posez ces questions ensemble. Les deux premières sont en texte libre (dites à l'utilisateur de les taper via le champ « Autre » ou de répondre dans le chat) ; les autres sont à choix multiples avec des options sensées. Incluez toujours un chemin « ajoutez le vôtre ».

1. Votre site web / produit — une URL (p. ex. www.acme.com) ou une brève description. C'est la source du contenu.
2. Site(s) de référence — une ou plusieurs URL dont le style doit être emprunté (p. ex. granola.ai, linear.app, stripe.com). C'est la source de l'apparence.
3. Style de police (sélection multiple) — p. ex. Sérif éditorial · Sans-serif épurée · Monospace/technique · Arrondie/amicale · Correspondre à la référence.
4. Thème (optionnel, sélection multiple) — p. ex. Clair / papier · Sombre / cinématographique · Bloc de couleur audacieux · Minimal / beaucoup d'espace blanc · Correspondre à la référence.

Ajoutez ces questions supplémentaires (elles changent matériellement le résultat) :

5. Ambiance / ton — Calme & éditorial · Cinématographique & dramatique · Ludique & optimiste · Corporate & digne de confiance.
6. Niveau de mouvement — Subtile (dévoilements doux) · Animation de défilement riche (parallaxe, sections liées au défilement) · Interactif (démo cliquable que le visiteur conduit). Par défaut : Animation de défilement riche.
7. Couleur d'accent — Correspondre à la référence · une couleur spécifique · laissez-moi choisir.
8. Profondeur — Hero + quelques sections · Histoire complète (tout raconter : fonctionnement, fonctionnalités, preuve, CTA). Par défaut : Histoire complète.
9. Sortie — Projet Next.js exécutable (recommandé) · Fichier HTML autonome.

Si l'utilisateur a déjà fourni certaines réponses dans son message, ne reposez pas celles-ci.

Étape 2 — Rechercher le(s) site(s) de référence

Vous devez réellement regarder la référence, pas deviner.

1. Essayez d'abord mcp__workspace__web_fetch. Les sites marketing sont généralement rendus côté client, donc il renvoie souvent vide — c'est attendu.
2. Passez aux outils de navigateur Chrome (chargez via ToolSearch si différé) : navigate → get_page_text pour le texte/la structure, puis captures d'écran computer (défilez et capturez 3 à 5 trames) pour lire le langage visuel réel. Acceptez les bannières de cookies avec l'option la plus respectueuse de la vie privée.
3. Obtenez un brouillon de preuve à moindre coût : collez scripts/extract-style.js dans l'outil javascript_tool de Chrome sur la page de référence ouverte — il renvoie les polices réelles, les fréquences de couleurs, l'échelle typographique et les rayons. Ensuite, rédigez la courte spécification de style (remplissez le schéma dans references/style-extraction.md) : fond, palette + accent, paire typographique, motifs de section/de mise en page, composants signatures (p. ex. maquettes de produit flottantes) et caractère du mouvement. Le script capture des valeurs que l'œil juge mal ; vos captures d'écran capturent la mise en page et les « indices » signatures. Utilisez les deux.
4. Lisez aussi le site de l'utilisateur de la même manière — pour le contenu réel du produit et pour noter sa propre structure de mise en page/squelette de sections, polices et pied de page. Vous en avez besoin pour pouvoir * diverger * délibérément de celui-ci (emprunter la structure de la référence, pas celle du produit) et pour pouvoir réutiliser le vrai pied de page/mentions légales du produit textuellement au lieu d'en inventer un.
5. Contenu non latin : si le texte du produit inclut du devanagari, du CJK, de l'arabe, du cyrillique, etc. (p. ex. une démo alternant hindi et anglais), notez-le maintenant — vous devez charger une police qui couvre cet alphabet (voir les pièges du guide de construction).

Si un domaine ne peut pas être récupéré ou est bloqué, informez l'utilisateur et continuez à partir de captures d'écran / de sa description — n'essayez jamais de contourner la restriction de récupération.

Étape 3 — Planifier

Mappez le contenu du produit de l'utilisateur sur les motifs structurels de la référence. Faites un court plan de section. Choisissez les polices (polices Google Fonts gratuites les plus proches de la référence), la palette et le plan de mouvement. Confirmez tout ce qui est vraiment ambigu, puis construisez.

Étape 4 — Construire

Pile par défaut : Next.js 14 (App Router, export statique) + GSAP ScrollTrigger + Lenis, CSS écrit à la main avec des jetons de design en haut de globals.css.

Échafaudez à partir du template — n'écrivez pas la pile à la main. Exécutez scripts/new-demo.sh <dest> ; il copie template/ (couche de mouvement déjà câblée et connue pour construire) et installe les dépendances. Ensuite :

1. Définissez les jetons de design dans app/globals.css :root à partir de votre spécification de style, et échangez les polices dans app/layout.tsx pour les polices Google Fonts correspondantes.
2. Remplacez app/page.tsx par les sections réelles — le contenu de l'utilisateur mappé sur le squelette de mise en page de la référence (pas celui du site de l'utilisateur).
3. Construisez le composant signature et choisissez 2 à 4 recettes de mouvement dans references/patterns.md ; references/build-guide.md contient les démarreurs d'onglets collants et de maquettes. Réutilisez .rise, [data-speed] et <Reveal> pour le reste.

Si l'utilisateur a choisi un fichier HTML unique, commencez plutôt par template-html/index.html (mêmes tokens + couche de mouvement, GSAP/Lenis via CDN, pas d'installation) et remplacez son contenu. Voir les notes de visite section par section du guide de construction pour une variante multi-thèmes.

Respectez toujours prefers-reduced-motion. Gardez la sensation de la référence mais écrivez un balisage et un texte originaux.

Étape 5 — Vérifier

Exécutez scripts/verify.sh <dir> — il vérifie les types, construit l'export statique et grep out/index.html. Ajoutez vos propres greps pour le texte réel du produit, le hex d'accent et le nom de la police (le script vous le rappelle). Corrigez jusqu'à ce que ce soit vert.

Regardez le résultat. Dans une session locale, vous pouvez le voir rendu : démarrez npm run dev, pointez les outils Chrome vers http://localhost:3000, et faites une capture d'écran computer (défilez). C'est le vrai contrôle qualité — faites-le, ne vous fiez pas seulement au grep. Dans un sandbox sans affichage où localhost n'est pas joignable, utilisez scripts/shoot.mjs http://localhost:3000 (ou contre un déploiement) pour des captures d'écran headless, et dites-le même si cela n'est pas disponible.

NE JAMAIS exécuter npm run build pendant que npm run dev tourne. Les deux écrivent dans .next ; la construction écrase les chunks du serveur de développement en plein vol et la page meurt avec Error: Cannot find module './31.js' (ou similaire). Cela nous a coincés et ressemble à un bug de code mais n'en est pas un. Pendant qu'un serveur de développement est actif :

• vérifiez les types avec npx tsc --noEmit (ne touche pas à .next) ;
• pour faire une vraie npm run build, arrêtez dev d'abord ;
• si le serveur de développement est déjà corrompu : pkill -f "next dev", rm -rf .next, puis redémarrez npm run dev.

Lors de l'édition d'un serveur de développement en cours, préférez tsc --noEmit + un curl localhost:3000 | grep pour votre contenu afin de confirmer qu'il a compilé, plutôt que de construire.

Étape 6 — Empaqueter et remettre

Supprimez node_modules, .next, out, zippez le projet et partagez-le avec mcp__cowork__present_files. Donnez les commandes d'exécution (npm install && npm run dev) et un résumé d'un paragraphe de la façon dont le style de la référence a été appliqué.

Étape 7 — Mise en ligne & audit (optionnel)

Si l'utilisateur souhaite une URL partageable ou un indicateur de qualité :

• Audit : scripts/audit.sh http://localhost:3000 (serveur de développement en cours) affiche les scores Lighthouse perf/a11y/best-practices/SEO. Visez 90+ ; l'accessibilité et le SEO sont les gains faciles à corriger avant le déploiement.
• Déploiement : construisez d'abord (scripts/verify.sh <dir> produit out/), puis scripts/deploy.sh out pour une URL de prévisualisation. Le déploiement est orienté vers l'extérieur — confirmez avec l'utilisateur avant scripts/deploy.sh out --prod, et ne déployez pas un out/ obsolète. Ce sont des fichiers statiques, donc Vercel/Netlify/n'importe quel hébergeur fonctionne.
• Ré-exécutez audit.sh <deploy-url> sur l'URL en ligne pour un score réseau réel.

Garde-fous

• Originalité : ne copiez jamais le texte de la référence, et n'intégrez pas ses logos ou ses actifs image sous marque déposée — utilisez plutôt des textures/formes générées par CSS. Les noms d'entreprise dans un contexte de comparaison/de mot sont acceptables.
• Domaines sensibles : si le produit est lié à la santé, la finance, le droit ou similaire, gardez un ton responsable et précis, étiquetez les données de démonstration comme illustratives, évitez les garanties et incluez des mentions appropriées (p. ex. une ligne de ressources de crise pour les sites de santé mentale). Gardez le langage de chargement/marketing non alarmant.
• Données illustratives : notez que tous les noms, chiffres, citations ou disponibilités affichés sont du contenu de démonstration fictif — mais gardez-le petit et discret (une courte ligne), jamais un énorme bloc d'avertissement, et jamais enfoncé dans le pied de page comme s'il s'agissait du pied de page du site. Si l'utilisateur souhaite le vrai pied de page du produit, reproduisez-le (voir ci-dessous) et glissez la note illustrative ailleurs ou supprimez-la s'il la remplace explicitement — puis dites-leur que rien ne marque plus les données de démonstration comme illustratives.
• Pied de page : préférez le vrai pied de page du produit cible — récupérez-le et réutilisez son slogan, ses liens et son copyright textuellement — plutôt que d'en inventer un ou de laisser une note de construction.
• Mouvement : chaque animation doit se dégrader gracieusement en mouvement réduit.

Pièges appris (NE PAS répéter)

Durement gagnés lors d'exécutions réelles. Détails techniques complets dans references/build-guide.md.

1. Recolorer ≠ restyler. Ne conservez pas le squelette de section du site de l'utilisateur et ne changez que les couleurs — cela ressemble toujours à son original. Empruntez la structure et les composants signatures de la référence. (Voir la Règle d'or.)
2. display:flex sur un élément de texte de liste / paragraphe contenant du balisage en ligne (<b>, <span>) sépare chaque course en ligne dans sa propre colonne flex — le texte se brise en colonnes brisées. Utilisez un ::before positionné pour les puces ; gardez les conteneurs de texte display:block. Ne mettez en flex que l'encapsuleur, jamais la ligne de prose elle-même.
3. Ne jamais npm run build pendant que npm run dev tourne (corrompt .next). Utilisez npx tsc --noEmit pour vérifier pendant que dev est actif. (Voir Étape 5.)
4. Les écritures non latines nécessitent leur propre police web. Le devanagari/CJK/arabe ne s'affichera pas dans Inter/JetBrains Mono ; chargez le next/font correspondant avec les bons subsets (p. ex. Noto_Sans_Devanagari, subsets:["devanagari"]) et appliquez une classe .hi{font-family:var(--f-deva)}. Ne comptez pas sur les polices de secours du système.
5. Réutilisez le vrai pied de page du produit, n'en inventez pas un et ne jetez pas une note de construction là-dedans (voir le garde-fou Pied de page).

Niveau de qualité

Visez quelque chose qui pourrait passer pour une vraie page de lancement : échelle typographique confiante, palette sobre, un élément visuel signature de la référence, et un mouvement qui révèle le contenu à mesure que vous défilez plutôt que de le décorer. Ne réutilisez pas la même mise en page pour différentes références — tout l'intérêt est que chaque résultat ressemble au site dont il a emprunté le style.