brandvm/webflow-build

Build Webflow : design approuvé → Webflow, section par section

La personne approuve chaque décision de design ; Claude construit, vérifie et rapporte. Une section est terminée uniquement lorsqu'elle correspond au design approuvé à toutes les largeurs, fonctionne après chaque façon d'y arriver, et que ses étapes manuelles sont listées.

• checklists.md verrouille chaque étape : la remise du design, les fondations Webflow, la page média, chaque composant, chaque page terminée et la remise de la construction. Leur progression est enregistrée dans docs/handoff/progress.json avec pnpm progress (checklists.md › Comment enregistrer la progression), que le panneau Tâches de Bench affiche.
• conventions.md définit la structure des pages et des sections, le nommage des classes et des variables, et les modèles de composants, CMS et guide de style à partir desquels chaque construction commence.
• lessons/ contient ce qui a coûté du temps lors des builds précédents, par domaine. Lisez le fichier pour le domaine dans lequel vous allez travailler.
• Le prototype vient toujours en premier : il est construit à partir du fichier Figma, page par page, dans Bench (ou par Claude dans le terminal avec les mêmes étapes), et le client l'approuve avant que quoi que ce soit ne soit construit dans Webflow. Les étapes sont ci-dessous (Le prototype, depuis Figma) ; la compétence webflow-prototype gère la configuration du projet, les entrées, l'instantané et le guide de style, et son figma.md explique comment lire le fichier.
• rules.md contient les règles partagées par chaque compétence Webflow (pas de commit ou de push sans OK, Designer d'abord, pas d'identifiants dans le chat, étapes manuelles, leçons), la conclusion de session et comment contribuer en retour.
• starter-site.md décrit le site Webflow de démarrage qu'un projet duplique, avec le système de base déjà intégré.
• La compétence webflow-style-guide crée la page guide de style, la première page du prototype et de la construction Webflow, dans la mise en page unique utilisée par tous les sites.
• media.md est la page média : là où les vidéos d'un site sont téléchargées pour que Webflow les convertisse et les héberge, construite avant la première page qui en lit une.
• Un site déjà en ligne n'est pas une construction : utilisez la compétence webflow-audit (audit, puis petits lots vérifiés ; également pour des correctifs ponctuels).
• Après la remise de la construction, la compétence webflow-launch prend le relais : QA pré-lancement, jour du lancement, remise au client et les 30 premiers jours.

Chaque élément de checklist indique qui le fait :

• [Claude] Claude le fait (via le MCP, le dépôt ou un script).
• [Claude vérifie] Claude le vérifie et rapporte ; une personne corrige ce que Claude ne peut pas.
• [Personne] une personne le fait (client, chef de projet, designer, DNS, comptes). Claude peut le rappeler et le suivre, mais ne jamais le revendiquer.

Début de session (chaque session)

1. Lisez le workspace CLAUDE.md, puis AGENTS.md et GOTCHAS.md de ce dépôt, puis docs/handoff/ (HANDOFF.md, MANUAL-TODO.md, BUILD-NOTES.md, et REVIEW.md une fois la phase de révision commencée). Parcourez lessons/README.md et lisez le fichier de leçon pour le domaine du jour (travail MCP : lessons/mcp.md). Ne répétez jamais une erreur déjà enregistrée.
2. Lisez la mémoire du projet : où la dernière session s'est arrêtée, les étapes manuelles ouvertes, les questions ouvertes. Exécutez pnpm progress show pour l'étape, les checklists encore ouvertes et les propres tâches de la personne. Dites en une ligne où en sont les choses et quelle est la prochaine étape ; demandez quelle page ou section si ce n'est pas clair.
3. Exécutez Avant de construire dans checklists.md avant le premier lot Webflow ; l'étape Prototype avant qu'il ne soit terminé (les entrées sont celles de webflow-prototype). Approuvez tout changement de conventions.md avec le designer. Si une entrée manque, demandez-la ; ne devinez pas le contenu, les états ou les champs SEO.
4. MCP Webflow : appelez webflow_guide_tool une fois, puis réutilisez un même identifiant de session et d'agent pour toute la session.
5. Le serveur de développement du prototype est en cours d'exécution et webflow-build.config.json existe (pnpm new-project l'écrit ; webflow-prototype › Configuration du projet).
6. Le périmètre du jour est une page (voir Rythme de travail). Dites laquelle.

Règles permanentes

Les règles partagées sont dans rules.md. La construction ajoute :

• Demandez avant de créer, modifier ou supprimer des classes et des variables, un lot à la fois, avec les noms et les valeurs. Une demande qui les implique clairement (par exemple "construis-le dans Webflow" après avoir approuvé une maquette) est l'accord.
• La publication dépend du fait que le site soit en ligne ou non.
  • Nouvelle construction (aucun domaine personnalisé attaché) : la publication sur le domaine de staging webflow.io est acceptable.
  • Site en ligne : une publication est à l'échelle du site. Elle envoie tout ce qui est en attente, y compris les modifications inachevées d'autres personnes. Publiez uniquement sur le staging, vérifiez ce qui partirait en production, et attendez que la personne tape "publier" avant le domaine personnalisé (webflow-audit contient les étapes).
  • Ne publiez jamais sur un domaine personnalisé, ne créez pas de version ou ne modifiez pas les DNS sans demander.
• Après chaque lot d'écriture Webflow, dites deux choses : "rechargez le Designer" (un onglet Designer ouvert n'affiche pas les modifications MCP, et l'enregistrement à partir d'un onglet obsolète peut les écraser), et ce qui n'est pas encore publié.
• Marquez les étapes manuelles sur la page. Une ligne MANUAL-TODO.md qui laisse quelque chose de visiblement inachevé (une valeur toujours manquante, une liaison non effectuée) reçoit un marqueur à côté de l'élément, ou à côté de son spécimen sur le guide de style : une légende avec data-manual-todo="<lettre>" et le texte "Étape manuelle : ". Cela s'affiche sur le canevas et sur le staging, afin que personne ne révise l'état inachevé comme étant le design. Supprimez-le dans le lot qui coche la ligne ; aucun ne doit rester lors de la remise de la construction ou au lancement (recherchez data-manual-todo dans le HTML publié).

Le prototype, depuis Figma

Chaque site commence par un fichier Figma. Le prototype est construit à partir de celui-ci, page par page, et approuvé avant que quoi que ce soit ne soit construit dans Webflow.

Dans Bench. Ajouter un client › à partir d'un design Figma configure le dossier client, le dépôt à partir de ce modèle et un prototype/ vide (une copie de prototype-starter/). Construire le prototype à partir de Figma regroupe les frames en pages ; la personne les choisit et les ordonne, chacune avec son adresse. Un seul job IA les construit ensuite une page à la fois : chaque page arrive comme son propre message avec les identifiants de nœud de ses frames. Chaque page construite conserve son frame Figma pour Comparer › Avec Figma. Bench examine à nouveau le fichier lorsque le client l'ouvre et toutes les heures, et propose de mettre à jour les pages dont les frames ont changé : ne modifiez que ce qui a changé dans ces frames et conservez les modifications effectuées dans le prototype depuis.

Pas dans Bench, Claude suit les mêmes étapes dans le terminal : listez les frames, convenez des pages, de leur ordre et de leurs adresses avec la personne, puis construisez une page à la fois.

Une page :

1. Ses frames. Les frames portant le même nom sur Desktop, Tablet et Mobile constituent une seule page. Lisez chacune avec le connecteur Figma (get_design_context, get_screenshot, get_variable_defs) ou le serveur MCP de l'application Figma (figma.md). Pas de frame Tablet : dessinez la Tablet entre Desktop et Mobile. Pas de frame Mobile : faites-la fonctionner sur un téléphone à partir des frames plus grandes, et dites-le. Les frames qui ne sont pas des pages (le guide de style) sont lues pour les tokens, les types et les composants.
2. Tokens à partir des variables et des styles de texte du fichier, en tant que propriétés personnalisées CSS : modifications des variables de l'instantané et nouvelles variables dans src/css/proposed.css (ancien → nouveau), nommées selon conventions.md §4 ; jamais dans le tokens.css généré.
3. Polices utilisées par les styles de texte, dans public/fonts/ avec leur licence, déclarées dans src/css/prototype.css et préchargées dans partials/head.html.
4. Images exportées du fichier vers prototype/images/ : photos en WebP à la plus grande taille utilisée par le design, icônes en SVG.
5. Uniquement ce qui se trouve dans le fichier. Une valeur, un état, un texte ou une image que le fichier ne fournit pas est une question : demandez avant de l'inventer (dans Bench, ajoutez-le avec mcp__bench__todo_add et continuez).
6. Où cela va : prototype/<page>/index.html à son adresse Webflow (Accueil est prototype/index.html), ajouté à pages dans prototype/vite.config.js. La navigation et le pied de page sont des partials partagés. Ne modifiez que cette page, plus les partials et les tokens dont elle a besoin. Ne faites pas de commit, de push ou de publication.
7. Vérifiez-la à côté de ses frames sur Desktop, Tablet et Mobile, et que les liens du prototype Figma fonctionnent (menus, onglets, formulaires).

Ensuite, la page exécute Page prototype terminée (la checklists.md de webflow-prototype) et la personne l'approuve (dans Bench : clic droit dans Pages). L'étape Prototype dans checklists.md suit tout cela, jusqu'à l'approbation écrite du client :

• chaque page correspond à son frame Figma sur Desktop, Tablet et Mobile (vérification "Correspond au frame Figma" de Bench) ;
• le fichier Figma est lié au client ;
• frames choisies, dans l'ordre, chacune avec son adresse de page ;
• chaque frame choisi est construit comme une page prototype ;
• les tokens, polices et images proviennent du fichier ; rien d'inventé ;
• les liens du prototype Figma fonctionnent ;
• chaque page approuvée dans le prototype ;
• le client a approuvé le prototype par écrit.

L'ordre d'une construction

Elle commence une fois l'étape Prototype terminée. La structure et les noms suivent conventions.md. Chaque étape est verrouillée dans checklists.md :

1. variables ;
2. styles de balise (définis une fois dans le Designer pour que le MCP puisse y accéder) ;
3. classes ;
4. collections CMS ;
5. le port du dépôt (modules et CSS du dépôt à partir du prototype) et le chargeur, pour que le staging exécute le vrai code → Fondations terminées ;
6. la page guide de style, la première page construite (compétence webflow-style-guide) → Base du guide de style terminée ;
7. la page média, lorsqu'une page lit une vidéo (media.md) → Média terminé ;
8. composants, construits à partir du vrai balisage de la page (jamais à partir des aperçus du guide de style), chacun ajoutant sa ligne au guide de style → Composant terminé ;
9. pages, section par section → Page terminée ;
10. la vérification finale du guide de style, puis Remise de la construction ;
11. la phase de révision : docs/handoff/REVIEW.md liste ce qui est construit par page, chaque tour de feedback et ce qui reste avant le lancement, jusqu'à ce que la compétence webflow-launch prenne le relais.

Un site dupliqué à partir du starter possède déjà la base des étapes 1 à 3 et la coquille de page ; le projet y ajoute. Avant chaque import, exécutez pnpm wf:preflight ; planifiez les lots de classes avec pnpm wf:styles (voir Vérifications).

La boucle de section

Pour chaque section, dans l'ordre des pages :

1. Lisez le prototype : son balisage, son CSS et le module qui l'anime, avec le frame Figma de la page pour les états et la spécification d'interaction. Notez chaque attribut data-*, id et aria.
2. Vérifiez ce que Webflow a : classes (query_styles), composants et leurs props, champs CMS, assets. Réutilisez avant de créer ; nommez toute nouveauté selon conventions.md (sections 2–4).
3. Construisez, en préférant, dans l'ordre :
   • des instances de composants ;
   • le constructeur d'éléments pour les éléments DOM (button, ul/li lorsque les rôles ARIA doivent survivre, svg, span avec balise), avec des enfants imbriqués ;
   • l'import WHTML pour le balisage simple, puis corrigez ce qu'il supprime (voir la checklist de l'importateur ci-dessous). Le contenu de la page vit dans l'emplacement G | Main du composant G | Page W. Sur une page dont l'emplacement est encore vide : construisez les sections dans un wrapper To Slot après G | Page W, demandez à la personne de faire glisser le wrapper dans l'emplacement, puis dégroupez-le (déplacez chaque enfant avant le wrapper, supprimez le wrapper). Une fois qu'une section est dans l'emplacement, construisez directement à côté (conventions.md §1). Vérifiez le contenu de l'emplacement avec query_elements ; l'arborescence de la page affiche les emplacements comme vides.
4. Câblez les attributs, les liaisons CMS, les valeurs de props, les liens, les paramètres de formulaire.
5. Publiez, puis exécutez les vérifications. Corrigez, republiez, revérifiez.
6. Rapportez : ce qui a été construit, ce qui correspond, ce qui diffère et pourquoi, les étapes manuelles et les fichiers en attente d'un OK pour le commit.

Lorsqu'une page est complète, exécutez Page terminée dans checklists.md.

Checklist de l'importateur (après chaque import WHTML)

• <button> est devenu un Lien → reconstruisez en tant que button DOM, déplacez les enfants à l'intérieur.
• <img> a perdu tous ses attributs et son lien d'asset → set_image_asset, rajoutez data-*, loading, la taille (ou une classe avec aspect-ratio).
• <span> est devenu un Span texte → les formes en tant que <div> ; les morceaux de texte divisés en tant que span DOM (sinon, la modification du texte du parent les aplatit).
• Une liste de classes avec une classe manquante a perdu toutes ses classes → créez d'abord les classes, revérifiez styleNames.
• Les éléments DOM conservent un attribut class littéral → remove_attribute class.
• Un espace normal avant <br> est supprimé → Line.&nbsp;<br>Next.
• Les attributs booléens ont besoin d'une valeur (muted="true") ou la publication les supprime.
• Les listes sont publiées avec role="list" → conservez les rôles ARIA sur les ul/li DOM.

Hygiène du canevas

• Chaque classe sur un élément vide : padding 0 sur tous les côtés et font-size: inherit (le .wf-empty du canevas ajoute 75px de padding et font-size 0).
• Chaque grille définit au moins un modèle de ligne et une colonne ; centrez les enfants uniques avec flex, pas de grille.
• Un élément dessiné uniquement par un pseudo-élément (un glyphe de police d'icône) reçoit un espace comme texte (set_settings, clé text), afin qu'il ne soit pas em