webflow-build

Webflow-Build: Genehmigtes Design → Webflow, Abschnitt für Abschnitt

Die Person genehmigt jede Design-Entscheidung; Claude baut, verifiziert und berichtet. Ein Abschnitt ist erst fertig, wenn er dem genehmigten Design auf jeder Breite entspricht, nach jeder Art des Aufrufens funktioniert und seine manuellen Schritte aufgelistet sind.

• checklists.md steuert jeden Schritt: die Design-Übergabe, das Webflow-Fundament, die Medienseite, jede Komponente, jede fertige Seite und die Build-Übergabe. Der Fortschritt wird in docs/handoff/progress.json mit pnpm progress (checklists.md › So wird Fortschritt aufgezeichnet) festgehalten, den das Aufgabenfeld von Bench anzeigt.
• conventions.md legt die Seiten- und Abschnittsstruktur, die Klassen- und Variablenbenennung sowie die Komponenten-, CMS- und Style-Guide-Muster fest, von denen jeder Build ausgeht.
• lessons/ enthält, was bei früheren Builds Zeit gekostet hat, nach Bereich gegliedert. Lies die Datei für den Bereich, an dem du gleich arbeiten wirst.
• Der Prototyp kommt immer zuerst: Er wird aus der Figma-Datei Seite für Seite in Bench (oder von Claude im Terminal mit denselben Schritten) erstellt und vom Kunden genehmigt, bevor etwas in Webflow gebaut wird. Die Schritte sind unten (Der Prototyp aus Figma) beschrieben; der Skill webflow-prototype umfasst die Projekteinrichtung, die Eingaben, den Snapshot und den Style-Guide, und in figma.md steht, wie die Datei gelesen wird.
• rules.md enthält die Regeln, die alle Webflow-Skills gemeinsam haben (kein Commit oder Push ohne OK, zuerst der Designer, keine Zugangsdaten im Chat, manuelle Schritte, Lessons), den Sitzungsabschluss und wie man zurückspielt.
• starter-site.md beschreibt die Webflow-Starterseite, die ein Projekt dupliziert, mit dem bereits enthaltenen Basissystem.
• Der Skill webflow-style-guide erstellt die Style-Guide-Seite, die erste Seite des Prototyps und des Webflow-Builds, im einheitlichen Layout, das jede Seite verwendet.
• media.md ist die Medienseite: Hier werden die Videos einer Seite hochgeladen, damit Webflow sie konvertiert und hostet. Sie wird vor der ersten Seite erstellt, die ein Video abspielt.
• Eine Seite, die bereits live ist, ist kein Build: Verwende den Skill webflow-audit (Audit, dann kleine verifizierte Batches; auch für einmalige Korrekturen).
• Nach der Build-Übergabe übernimmt der Skill webflow-launch: Pre-Launch-QA, Launch-Tag, Kundenübergabe und die ersten 30 Tage.

Jeder Checklistenpunkt sagt, wer ihn macht:

• [Claude] Claude macht es (über das MCP, das Repo oder ein Skript).
• [Claude prüft] Claude verifiziert es und berichtet; eine Person behebt, was Claude nicht kann.
• [Person] Eine Person macht es (Kunde, PM, Designer, DNS, Accounts). Claude darf es erinnern und verfolgen, aber niemals beanspruchen.

Sessionsstart (jede Session)

1. Lies den Workspace CLAUDE.md, dann die AGENTS.md und GOTCHAS.md dieses Repos, dann docs/handoff/ (HANDOFF.md, MANUAL-TODO.md, BUILD-NOTES.md und REVIEW.md, sobald die Überprüfungsphase begonnen hat). Überfliege lessons/README.md und lies die Lesson-Datei für den heutigen Bereich (MCP-Arbeit: lessons/mcp.md). Wiederhole niemals einen bereits protokollierten Fehler.
2. Lies den Projektverlauf: wo die letzte Session aufgehört hat, offene manuelle Schritte, offene Fragen. Führe pnpm progress show aus für die Phase, die noch offenen Checklisten und die eigenen Todos der Person. Sage in einem Satz, wo die Dinge stehen und was als nächstes kommt; frage, welche Seite oder welcher Abschnitt, wenn es nicht klar ist.
3. Führe Vor dem Bauen in checklists.md vor dem ersten Webflow-Batch aus; die Prototyp-Phase, bevor sie abgeschlossen ist (die Eingaben sind die von webflow-prototype). Stimme jede Änderung an conventions.md mit dem Designer ab. Wenn eine Eingabe fehlt, frage danach; rate keine Inhalte, Zustände oder SEO-Felder.
4. Webflow MCP: Rufe webflow_guide_tool einmal auf und verwende dann eine Session-ID und Agent-ID für die gesamte Session.
5. Der Prototyp-Entwicklungsserver läuft und webflow-build.config.json existiert (pnpm new-project schreibt es; webflow-prototype › Projekteinrichtung).
6. Der heutige Umfang ist eine Seite (siehe Arbeitsrhythmus). Sage, welche.

Stehende Regeln

Die gemeinsamen Regeln stehen in rules.md. Der Build fügt hinzu:

• Frage, bevor du Klassen und Variablen erstellst, bearbeitest oder entfernst, einen Batch nach dem anderen, mit Namen und Werten. Eine Anfrage, die sie eindeutig impliziert (z. B. „baue es in Webflow“ nach Genehmigung eines Mockups), ist das OK.
• Das Veröffentlichen hängt davon ab, ob die Seite live ist.
  • Neuer Build (keine benutzerdefinierte Domain angeschlossen): Die Veröffentlichung auf der webflow.io-Staging-Domain ist in Ordnung.
  • Live-Seite: Eine Veröffentlichung ist seitenweit. Sie sendet alles Ausstehende raus, einschließlich unfertiger Bearbeitungen anderer Personen. Nur auf Staging veröffentlichen, prüfen, was sonst noch live gehen würde, und warten, bis die Person „publish“ tippt, bevor die benutzerdefinierte Domain verwendet wird (webflow-audit hat die Schritte).
  • Veröffentliche niemals auf einer benutzerdefinierten Domain, führe kein Release durch und ändere kein DNS ohne zu fragen.
• Sage nach jedem Webflow-Schreibbatch zwei Dinge: „lade den Designer neu“ (ein geöffneter Designer-Tab zeigt MCP-Änderungen nicht an, und das Speichern von einem veralteten Tab kann sie überschreiben), und was noch nicht veröffentlicht ist.
• Markiere manuelle Schritte auf der Seite. Ein MANUAL-TODO.md-Eintrag, der etwas sichtbar Unfertiges hinterlässt (ein noch fehlender Wert, eine nicht erstellte Bindung), erhält einen Marker neben dem Element oder neben seinem Exemplar auf dem Style-Guide: eine Beschriftung mit data-manual-todo="<buchstabe>" und dem Text „Manueller Schritt : ". Es wird auf der Leinwand und auf dem Staging angezeigt, damit niemand den unfertigen Zustand als das Design überprüft. Entferne es in dem Batch, der den Eintrag abhakt; beim Build-Handoff oder beim Launch darf keins mehr übrig sein (durchsuche das veröffentlichte HTML nach data-manual-todo).

Der Prototyp aus Figma

Jede Seite beginnt mit einer Figma-Datei. Der Prototyp wird daraus Seite für Seite erstellt und genehmigt, bevor irgendetwas in Webflow gebaut wird.

In Bench. „Kunde hinzufügen › aus einem Figma-Design“ richtet den Kundenordner, das Repo aus dieser Vorlage und ein leeres prototype/ (eine Kopie von prototype-starter/) ein. „Prototyp aus Figma erstellen“ gruppiert die Frames in Seiten; die Person wählt sie aus und ordnet sie an, jede mit ihrer Adresse. Ein KI-Job erstellt sie dann eine Seite nach der anderen: Jede Seite kommt als eigene Nachricht mit den Node-IDs ihrer Frames. Jede erstellte Seite behält ihren Figma-Frame für „Vergleichen › Mit Figma“. Bench überprüft die Datei erneut, wenn der Kunde sie öffnet, und stündlich, und bietet an, die Seiten zu aktualisieren, deren Frames sich geändert haben: Ändere nur, was sich in diesen Frames geändert hat, und behalte Bearbeitungen bei, die seitdem im Prototyp vorgenommen wurden.

Nicht in Bench – Claude folgt denselben Schritten im Terminal: Liste die Frames auf, stimme die Seiten, ihre Reihenfolge und Adressen mit der Person ab und erstelle dann eine Seite nach der anderen.

Eine Seite:

1. Ihre Frames. Frames mit demselben Namen auf Desktop, Tablet und Mobile sind eine Seite. Lese jeden mit dem Figma-Konnektor (get_design_context, get_screenshot, get_variable_defs) oder dem MCP-Server der Figma-App (figma.md). Kein Tablet-Frame: Zeichne Tablet zwischen Desktop und Mobile. Kein Mobile-Frame: Sorge dafür, dass es auf einem Telefon von den größeren Frames aus funktioniert, und sage das. Frames, die keine Seiten sind (der Style-Guide), werden nach Tokens, Typ und Komponenten gelesen.
2. Tokens aus den Variablen und Textstilen der Datei als CSS-Custom-Properties: Änderungen an den Variablen des Snapshots und neue in src/css/proposed.css (alt → neu), benannt nach conventions.md §4; niemals im generierten tokens.css.
3. Schriftarten, die die Textstile verwenden, in public/fonts/ mit ihrer Lizenz, deklariert in src/css/prototype.css und vorab geladen in partials/head.html.
4. Bilder, die aus der Datei in prototype/images/ exportiert werden: Fotos als WebP in der größten Größe, die das Design verwendet, Icons als SVG.
5. Nur das, was in der Datei ist. Ein Wert, Zustand, Text oder Bild, den die Datei nicht liefert, ist eine Frage: Frage, bevor du es erfindest (in Bench füge es mit mcp__bench__todo_add hinzu und fahre fort).
6. Wohin es geht: prototype/<seite>/index.html unter seiner Webflow-Adresse (Startseite ist prototype/index.html), hinzugefügt zu pages in prototype/vite.config.js. Nav und Footer sind gemeinsame Partials. Ändere nur diese Seite, plus die Partials und Tokens, die sie benötigt. Committe, pushe oder veröffentliche nicht.
7. Überprüfe es neben seinen Frames auf Desktop, Tablet und Mobile und dass die Links des Figma-Prototyps funktionieren (Menüs, Tabs, Formulare).

Dann läuft Prototypseite fertig (checklists.md von webflow-prototype) und die Person genehmigt sie (in Bench: Rechtsklick in Seiten). Die Prototyp-Phase in checklists.md verfolgt alles bis zur schriftlichen Genehmigung des Kunden:

• jede Seite stimmt mit ihrem Figma-Frame auf Desktop, Tablet und Mobile überein (Bench-Prüfung „Stimmt mit dem Figma-Frame überein“);
• die Figma-Datei ist mit dem Kunden verlinkt;
• Frames ausgewählt, in der richtigen Reihenfolge, jeder mit seiner Seitenadresse;
• jeder ausgewählte Frame wurde als Prototypseite erstellt;
• Tokens, Schriftarten und Bilder stammen aus der Datei; nichts wurde erfunden;
• die Links des Figma-Prototyps funktionieren;
• jede Seite wurde im Prototyp genehmigt;
• der Kunde hat den Prototyp schriftlich genehmigt.

Die Reihenfolge eines Builds

Sie beginnt, sobald die Prototyp-Phase abgeschlossen ist. Struktur und Namen folgen conventions.md. Jeder Schritt wird in checklists.md gesteuert:

1. Variablen;
2. Tag-Stile (einmal im Designer gesetzt, damit das MCP darauf zugreifen kann);
3. Klassen;
4. CMS-Sammlungen;
5. der Repo-Port (Module und Repo-CSS aus dem Prototypen) und der Loader, damit das Staging den echten Code ausführt → Fundament fertig;
6. die Style-Guide-Seite, die erste erstellte Seite (webflow-style-guide Skill) → Style-Guide-Basis fertig;
7. die Medienseite, wenn irgendeine Seite ein Video abspielt (media.md) → Medien fertig;
8. Komponenten, erstellt aus dem echten Seiten-Markup (niemals aus Style-Guide-Vorschauen), jede fügt ihre Style-Guide-Zeile hinzu → Komponente fertig;
9. Seiten, Abschnitt für Abschnitt → Seite fertig;
10. die abschließende Style-Guide-Überprüfung, dann Build-Übergabe;
11. die Überprüfungsphase: docs/handoff/REVIEW.md listet auf, was pro Seite erstellt wurde, jede Feedback-Runde und was vor dem Launch noch übrig ist, bis der Skill webflow-launch übernimmt.

Eine von der Starterseite duplizierte Seite hat bereits die Basis der Schritte 1 bis 3 und das Seiten-Gerüst; das Projekt fügt hinzu. Führe vor jedem Import pnpm wf:preflight aus; plane Klassenbatches mit pnpm wf:styles (siehe Überprüfungen).

Der Abschnitts-Loop

Für jeden Abschnitt in Seitenreihenfolge:

1. Lies den Prototypen: sein Markup, CSS und das Modul, das ihn animiert, mit dem Figma-Frame der Seite für Zustände und die Interaktionsspezifikation. Notiere jeden data-*-Hook, jede ID und jedes aria-Attribut.
2. Überprüfe, was Webflow hat: Klassen (query_styles), Komponenten und ihre Props, CMS-Felder, Assets. Verwende wieder, bevor du etwas neu erstellst; benenne alles Neue nach conventions.md (Abschnitte 2–4).
3. Baue, bevorzuge in dieser Reihenfolge:
   • Komponenteninstanzen;
   • den Element-Builder für DOM-Elemente (button, ul/li wenn ARIA-Rollen überleben müssen, svg, span mit Tag), mit verschachtelten Kindern;
   • WHTML-Import für einfaches Markup, dann behebe, was fallen gelassen wurde (siehe Importer-Checkliste unten). Seiteninhalt lebt im G | Main-Slot der G | Page W-Komponente. Auf einer Seite, deren Slot noch leer ist: Baue die Abschnitte in einem To Slot-Wrapper nach G | Page W, bitte die Person, den Wrapper in den Slot zu ziehen, dann entgruppe ihn (verschiebe jedes Kind vor den Wrapper, entferne den Wrapper). Sobald ein Abschnitt im Slot ist, baue direkt daneben (conventions.md §1). Überprüfe den Slot-Inhalt mit query_elements; der Seitenbaum zeigt Slots als leer an.
4. Verdrahte Attribute, CMS-Bindungen, Prop-Werte, Links, Formulareinstellungen.
5. Veröffentliche, dann führe die Überprüfungen durch. Korrigiere, veröffentliche erneut, überprüfe erneut.
6. Berichte: was gebaut wurde, was übereinstimmt, was abweicht und warum, manuelle Schritte und die Dateien, die auf ein Commit-OK warten.

Wenn eine Seite vollständig ist, führe Seite fertig in checklists.md aus.

Importer-Checkliste (nach jedem WHTML-Import)

• <button> wurde zu einem Link → baue es als DOM button neu, verschiebe Kinder hinein.
• <img> verlor jedes Attribut und seinen Asset-Link → set_image_asset, füge data-*, loading, Größe (oder eine Klasse mit aspect-ratio) wieder hinzu.
• <span> wurde zu einem Text-Span → forme als <div>; teile Textstücke als DOM span (sonst werden sie beim Bearbeiten des übergeordneten Textes eingeebnet).
• Eine Klassenliste mit einer fehlenden Klasse verlor alle ihre Klassen → erstelle zuerst Klassen, überprüfe styleNames erneut.
• DOM-Elemente behalten ein literales class-Attribut → remove_attribute class.
• Ein normaler Leerzeichen vor <br> wird abgeschnitten → Line.&nbsp;<br>Next.
• Boolesche Attribute benötigen einen Wert (muted="true") oder die Veröffentlichung lässt sie weg.
• Listen veröffentlichen als role="list" → behalte ARIA-Rollen auf DOM ul/li.

Leinwand-Hygiene

• Jede Klasse auf einem leeren Element: Padding 0 auf allen Seiten und font-size: inherit (die Leinwand .wf-empty fügt 75px Padding und Schriftgröße 0 hinzu).
• Jedes Grid setzt mindestens eine Zeilen- und eine Spaltenvorlage; zentriere einzelne Kinder mit Flex, nicht mit Grid.
• Ein Element, das nur durch ein Pseudoelement gezeichnet wird (ein Icon-Font-Glyph), erhält ein Leerzeichen als Text (set_settings, Schlüssel text), damit es nicht em ist