brandvm/webflow-prototype

Prototype Webflow : maquette Figma → prototype localhost approuvé

La première phase d’un projet. Chaque site part d’un fichier Figma, et sa conception est construite en code, aux vraies URLs et points de rupture, avec les variables et noms de classes que Webflow utilisera, et approuvée page par page. Ce qui en ressort n’est pas une maquette : c’est le balisage, les classes, les modules et la liste des étapes manuelles à partir desquelles le build Webflow commence.

Cette phase n’écrit jamais dans Webflow. Elle lit le site (l’instantané) et propose des changements ; les écritures appartiennent au skill webflow-build, dans sa propre session, après approbation du prototype.

• checklists.md contrôle les entrées, chaque page du prototype et le transfert.
• prototype-starter/ est le dossier prototype à partir duquel un projet démarre (pnpm new-project le copie).
• figma.md lit le fichier Figma via le connecteur Figma : cadres par point de rupture, captures d’écran, variables, mesures.
• Les étapes qui construisent une page à partir de ses cadres se trouvent dans webflow-build (SKILL.md › Le prototype, depuis Figma), les mêmes que suit l’IA de Bench. L’étape Prototype de sa checklists.md suit le prototype jusqu’à l’approbation du client.
• Le skill webflow-style-guide réalise le guide de style, la première page du prototype.
• conventions.md (dans webflow-build) définit la structure des pages et des sections ainsi que le nommage des classes et des variables suivi par le prototype ; lessons/ contient ce qui a coûté du temps lors des builds précédents.
• rules.md contient les règles partagées par tous les skills Webflow (pas de commit ni de push sans accord, Designer d’abord, pas d’identifiants dans le chat), la clôture de session et comment contribuer.

Chaque élément de checklist indique qui le fait : [Claude], [Claude vérifie] (Claude vérifie et rapporte ; une personne corrige ce que Claude ne peut pas) ou [Personne] (Claude peut rappeler et suivre, mais ne jamais le faire).

Début de session (chaque session)

1. Lire le fichier CLAUDE.md de l’espace de travail, puis AGENTS.md et GOTCHAS.md du dépôt, puis docs/handoff/. Parcourir lessons/README.md ; les leçons de l’importateur dans lessons/mcp.md déterminent comment le balisage du prototype est écrit.
2. Lire la mémoire du projet : là où la session précédente s’est arrêtée, questions ouvertes. Dire en une ligne où en sont les choses et quelle est la prochaine étape.
3. Pour un nouveau projet, exécuter d’abord Avant le prototype dans checklists.md. Si une entrée manque, la demander ; ne pas deviner le contenu, les états ou les champs SEO.
4. Le serveur de développement du prototype tourne (pnpm dev dans prototype/).
5. Le périmètre du jour est une page. Le dire.

Configuration du projet (nouveau projet)

Dans Bench, "Add client › from a Figma design" configure le dossier client, le dépôt à partir de ce template et un dossier prototype/ vide, puis construit le prototype à partir des cadres que la personne choisit (étape 6). Les étapes de la personne (4) et les entrées s’appliquent toujours.

Pas dans Bench, le flux commence par un message (README › Démarrer un projet), par exemple "Nouveau projet : site Webflow , Figma . Configure le dépôt et l’espace de travail, exécute Avant le prototype, puis construit le prototype à partir du fichier Figma page par page ; attends mon feu vert avant toute modification Webflow."

Avant cela, une personne a créé le dépôt à partir du template sur GitHub, l’a cloné dans son propre dossier client (<Client>/wf-<Client>/), et a dupliqué le site de démarrage sous le nom du client (starter-site.md).

1. D’abord les skills. Proposer pnpm update-skills (demander ; cela remplace les modifications locales des skills), afin que le projet démarre avec les dernières leçons.

2. Trouver le site. Via le connecteur Webflow, lister les sites et faire correspondre le nom donné par la personne : l’ID du site et le nom court (le sous-domaine de staging, <nom court>.webflow.io). Deux correspondances ou aucune → demander. Lire l’organisation GitHub et le dépôt depuis git remote get-url origin.

3. Remplir le dépôt et configurer l’espace de travail :

   pnpm install
   pnpm new-project --client "<Client>" --slug <nom court> --org <org> --site-id <id>
   

   Cela remplit les informations du projet dans AGENTS.md, le nom dans package.json, REPO dans loader.html et le titre du transfert, et écrit webflow-build.config.json. Autour du dépôt, cela crée l’espace de travail : <Client>/CLAUDE.md (importe AGENTS.md, GOTCHAS.md et docs/handoff/), .mcp.json, des liens vers les skills, prototype/ (une copie de prototype-starter/) et Assets/. Écrire le lien Figma dans le fichier CLAUDE.md de l’espace de travail (ligne Design). Demander toute valeur introuvable ; ne jamais deviner.

4. Lister les étapes de la personne, dans cet ordre, et les suivre dans docs/handoff/MANUAL-TODO.md jusqu’à réalisation :

   1. Paramètres du dépôt › Pages › Source : GitHub Actions ; ajouter l’équipe des développeurs.
   2. Premier push : Claude demande à valider la configuration ; après le push, le workflow de staging doit passer (https://<org>.github.io/<repo>/styles.css se charge).
   3. Coller le loader depuis loader.html (ORG et REPO sont maintenant renseignés) : code head et code footer dans les paramètres du site. Les embeds 2a et 2b se trouvent déjà dans G | Composants avec des espaces réservés : Claude les remplit via le MCP après le feu vert, ou la personne les colle.
   4. Mot de passe de staging et noindex jusqu’au lancement.

5. Passer à l’espace de travail. Dès la session suivante, Claude est ouvert dans <Client>/, pas dans le dépôt : c’est là que sont configurés le serveur MCP, les skills et les imports. Exécuter pnpm install dans prototype/.

6. Entrées, puis le prototype. Exécuter Avant le prototype dans checklists.md (cela inclut le plan des composants et la liste des vidéos), lire le fichier Figma (figma.md), prendre l’instantané Webflow, et construire le prototype à partir du fichier : d’abord le guide de style (skill webflow-style-guide), approuvé avant toute page de contenu, puis page par page à partir des cadres choisis (webflow-build › Le prototype, depuis Figma), chacune passant Page prototype terminée.

7. Remplir docs/handoff/HANDOFF.md à partir de la maquette ; tenir à jour MANUAL-TODO.md et BUILD-NOTES.md dès la première session.

Le prototype

• Il reflète Webflow : les mêmes URLs, les mêmes points de rupture (991, 767, 479), les noms de classes Webflow, et la structure des enveloppes de page et de section de conventions.md. La navigation et le pied de page sont des partials uniques (un composant chacun).
• Il marque les composants et le CMS : data-component="<Nom du composant>" sur la racine d’une instance de composant (le Nav et le Footer des partials ont les leurs), data-prop="<Nom de la propriété>" sur ce qu’une propriété de composant définit, data-collection="<Nom de la collection>" sur un wrapper de Collection List et data-field="<Nom du champ>" sur un élément lié à un champ CMS (dans un élément de liste ou sur une page de template CMS). Rien de visible ne change, et ils ne sont pas réalisés dans Webflow, qui a ses propres composants et liaisons CMS (prototype-starter/README.md › Marqueurs de composant et CMS).
• Il lit les variables du site à partir d’un instantané de Webflow (prototype-starter/README.md › Instantané Webflow). Après avoir écrit ou actualisé l’instantané : pnpm css, puis pnpm check:snapshot, puis pnpm check:drift, qui compare l’instantané avec la feuille de style publiée par le site de staging et liste chaque variable, classe et valeur qui diffère (publier d’abord sur le staging).
• Pas de connecteur Webflow ? (pas encore configuré, connecté à un autre site, ou aucun appel MCP autorisé) pnpm css:published <URL de staging> construit tokens.css, webflow.css et webflow-base.css à partir du CSS publié par le site (GET uniquement ; le CSS par page est lu page par page et fusionné), et récupère l’instantané dans la mesure du possible. Le CSS est exact ; les noms du Designer, les noms de modes, les classes vides et les interactions n’y figurent pas (l’en-tête du script liste tout ce qu’il devine), donc dire dans HANDOFF.md que l’instantané est un substitut, ne jamais proposer une variable ou une classe avec un nom deviné sans la vérifier dans le Designer, et remplacer l’instantané depuis le MCP dès qu’il est disponible (supprimer webflow-snapshot/source.json, puis pnpm css). Tant que source.json existe, pnpm css refuse de s’exécuter.
• Les changements de variables sont proposés, jamais effectués : sous forme d’ancien → nouveau dans proposed.css, regroupés et lettrés pour approbation. Les nouvelles classes vont dans new-classes*.css, écrites comme le Designer peut les contenir.
• Le balisage est écrit pour l’importateur : les formes sont des div, pas des spans vides ; les contrôles de formulaire se trouvent dans un <form> ; les attributs booléens portent une valeur ; un saut de ligne a   avant lui ; les modules dépendent d’accroches data-*, pas de noms de classes. pnpm wf:preflight vérifie tout cela.

Ordre.

1. Instantané, pnpm css, pnpm check:snapshot, pnpm check:drift (pas de connecteur : pnpm css:published, puis les mêmes vérifications).
2. Le guide de style (skill webflow-style-guide), approuvé avant toute page de contenu.
3. Pages, une par une, à partir de leurs cadres Figma (webflow-build › Le prototype, depuis Figma). Pour chacune : la construire ; ajouter la ligne pour chaque classe ou composant qu’elle a introduit (pnpm style-guide) ; pnpm screens (toutes les largeurs de 2560 à 360 : débordement et erreurs) et pnpm check:states (états focus et pressed) ; exécuter Page prototype terminée ; la personne l’approuve à 1440, 820, 667 et 390.
4. Le client approuve le prototype par écrit.
5. Le transfert (ci-dessous).

Transfert vers le build

Exécuter Transfert du prototype dans checklists.md. Le pack à partir duquel la session de build démarre :

• docs/handoff/HANDOFF.md : pages, variables et classes, CMS, composants à réaliser, modules et leurs accroches, la liste des vidéos.
• pnpm wf:styles : chaque nouvelle classe triée en fonction de ce que le connecteur peut créer, de ce qu’une personne définit à la main dans le Designer (déjà des lignes dans MANUAL-TODO.md) et de ce qui va dans le CSS du dépôt.
• pnpm wf:preflight : les étapes connues de l’importateur par page.
• Le prototype approuvé lui-même, en cours d’exécution, comme référence à laquelle le build est comparé (pnpm wf:compare, pnpm wf:pass).

Ensuite, donner à la personne le message qui démarre la session de build, rempli, à coller dans une nouvelle session ouverte dans le dossier de l’espace de travail :

Continuer : build dans Webflow. Le prototype est approuvé (toutes les pages et le guide de style, ). Lire le workspace CLAUDE.md, docs/handoff/ et le skill webflow-build. Commencer par les fondations : proposer le lot de variables depuis proposed.css et attendre mon feu vert avant chaque écriture Webflow. Ensuite, baliser les styles, les classes (d’après le plan de styles), les collections CMS, le port du dépôt et le loader, la page du guide de style, la page média (si la liste des vidéos a des entrées), les composants et les pages, une page par session.

Le build s’exécute dans sa propre session afin de ne charger que les règles de build, et pour que le prototype reste intact comme référence.

Rythme de travail

• Une page par session, terminée complètement : construite, vérifiée à toutes les largeurs, ses états terminés, Page prototype terminée exécutée, transfert mis à jour.
• docs/handoff/ reste à jour pendant la session, pas à la fin : une décision va dans HANDOFF.md dès qu’elle est prise.
• Les leçons sont réintégrées. Lors de la clôture, proposer chaque leçon template-candidate au template (rules.md › Contribuer).