brandvm/webflow-prototype

Webflow-Prototyp: Figma-Design → freigegebener lokaler Prototyp

Die erste Phase eines Projekts. Jede Website beginnt mit einer Figma-Datei, deren Design in Code umgesetzt wird – mit den echten URLs und Breakpoints, den Variablen und Klassennamen, die Webflow verwenden wird, und Seite für Seite freigegeben. Das Ergebnis ist kein Mockup: Es ist das Markup, die Klassen, die Module und die Liste der manuellen Schritte, von denen der Webflow-Build ausgeht.

Diese Phase schreibt niemals in Webflow. Sie liest die Website (den Snapshot) und schlägt Änderungen vor; die Schreibvorgänge gehören zur webflow-build-Skill, in einer eigenen Sitzung, nachdem der Prototyp freigegeben wurde.

• checklists.md prüft die Eingaben, jede Prototyp-Seite und die Übergabe.
• prototype-starter/ ist der Prototyp-Ordner, von dem ein Projekt ausgeht (pnpm new-project kopiert ihn).
• figma.md liest die Figma-Datei über den Figma-Connector: Frames pro Breakpoint, Screenshots, Variablen, Maße.
• Die Schritte zum Erstellen einer Seite aus ihren Frames befinden sich in webflow-build (SKILL.md › Der Prototyp, aus Figma) – die gleichen, die Bench's KI befolgt. Die Prototyp-Phase seiner checklists.md verfolgt den Prototyp bis zur Freigabe durch den Kunden.
• Die webflow-style-guide-Skill erstellt den Styleguide, die erste Seite des Prototyps.
• conventions.md (in webflow-build) legt die Seiten- und Abschnittsstruktur sowie die Klassen- und Variablenbenennung fest, die der Prototyp befolgt; lessons/ enthält, was bei früheren Builds Zeit gekostet hat.
• rules.md enthält die Regeln, die alle Webflow-Skills teilen (kein Commit oder Push ohne OK, Designer first, keine Anmeldedaten im Chat), den Sitzungsabschluss und wie man beiträgt.

Jeder Checklisten-Eintrag sagt, wer ihn ausführt: [Claude], [Claude prüft] (Claude verifiziert und berichtet; eine Person behebt, was Claude nicht kann) oder [Person] (Claude darf erinnern und verfolgen, aber nie ausführen).

Sitzungsstart (jede Sitzung)

1. Lies das Workspace-CLAUDE.md, dann das Repo-AGENTS.md und GOTCHAS.md, dann docs/handoff/. Überfliege lessons/README.md; die Importer-Lektionen in lessons/mcp.md bestimmen, wie Prototyp-Markup geschrieben wird.
2. Lies den Projektspeicher: wo die letzte Sitzung aufgehört hat, offene Fragen. Sage in einem Satz, wo die Dinge stehen und was als nächstes kommt.
3. Bei einem neuen Projekt führe zuerst Vor dem Prototyp in checklists.md aus. Wenn eine Eingabe fehlt, frage danach; rate nicht bei Inhalten, Zuständen oder SEO-Feldern.
4. Der Prototyp-Entwicklungsserver läuft (pnpm dev in prototype/).
5. Der heutige Umfang ist eine Seite. Sage, welche.

Projekteinrichtung (neues Projekt)

In Bench richtet „Client hinzufügen › aus einem Figma-Design“ den Client-Ordner, das Repo aus dieser Vorlage und ein leeres prototype/ ein und erstellt dann den Prototyp aus den Frames, die die Person auswählt (Schritt 6). Die Schritte der Person (4) und die Eingaben gelten weiterhin.

Nicht in Bench beginnt der Ablauf mit einer Nachricht (README › Ein Projekt starten), z.B. „Neues Projekt: Webflow-Website , Figma . Richte das Repo und das Workspace ein, führe „Vor dem Prototyp“ aus und erstelle dann den Prototyp aus der Figma-Datei Seite für Seite; warte auf mein Go-ahead, bevor du Webflow änderst.“

Davor hat eine Person das Repo aus der Vorlage auf GitHub erstellt, in den eigenen Client-Ordner (<Client>/wf-<Client>/) geklont und die Starter-Seite unter dem Client-Namen dupliziert (starter-site.md).

1. Skills zuerst. Biete pnpm update-skills an (fragen; es ersetzt lokale Skill-Bearbeitungen), damit das Projekt mit den neuesten Lektionen startet.

2. Die Website finden. Liste über den Webflow-Connector die Websites auf und gleiche den von der Person genannten Namen ab: die Website-ID und der Kurzname (die Staging-Subdomain <kurzname>.webflow.io). Zwei Treffer oder keiner → frage. Lies die GitHub-Organisation und das Repo aus git remote get-url origin.

3. Repo befüllen und Workspace einrichten:

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

   Es füllt die Projektfakten in AGENTS.md, den package.json-Namen, REPO in loader.html und den Übergabetitel und schreibt webflow-build.config.json. Im Workspace erstellt es: <Client>/CLAUDE.md (importiert AGENTS.md, GOTCHAS.md und docs/handoff/), .mcp.json, Verknüpfungen zu den Skills, prototype/ (eine Kopie von prototype-starter/) und Assets/. Schreibe den Figma-Link in das Workspace-CLAUDE.md (Design-Zeile). Frage nach jedem Wert, den du nicht finden kannst; rate niemals.

4. Liste die Schritte der Person in dieser Reihenfolge auf und verfolge sie in docs/handoff/MANUAL-TODO.md bis zur Erledigung:

   1. Repo-Einstellungen → Pages → Quelle: GitHub Actions; füge das Entwickler-Team hinzu.
   2. Erster Push: Claude bittet, das Setup zu committen; nach dem Push muss der Staging-Workflow bestehen (https://<org>.github.io/<repo>/styles.css lädt).
   3. Füge den Loader aus loader.html ein (ORG und REPO sind jetzt ausgefüllt): Head-Code und Footer-Code in den Site-Einstellungen. Die Embeds 2a und 2b befinden sich bereits in G | Components mit Platzhaltern: Claude füllt sie nach dem Go-ahead über den MCP aus, oder die Person fügt sie ein.
   4. Staging-Passwort und noindex bis zum Launch.

5. Wechsel zum Workspace. Ab der nächsten Sitzung wird Claude in <Client>/ geöffnet, nicht im Repo: Dort sind der MCP-Server, die Skills und die Imports eingerichtet. Führe pnpm install in prototype/ aus.

6. Eingaben, dann der Prototyp. Führe Vor dem Prototyp in checklists.md aus (es enthält den Komponentenplan und die Videoliste), lies die Figma-Datei (figma.md), erstelle den Webflow-Snapshot und baue den Prototyp aus der Datei: zuerst den Styleguide (webflow-style-guide-Skill), freigegeben vor jeder Inhaltsseite, dann Seite für Seite aus den ausgewählten Frames (webflow-build › Der Prototyp, aus Figma), jede besteht Prototyp-Seite fertig.

7. Fülle docs/handoff/HANDOFF.md aus dem Design aus; halte MANUAL-TODO.md und BUILD-NOTES.md ab der ersten Sitzung aktuell.

Der Prototyp

• Er spiegelt Webflow: die gleichen URLs, die gleichen Breakpoints (991, 767, 479), die Webflow-Klassennamen und die Seitenhülle und Abschnittsstruktur von conventions.md. Nav und Footer sind einzelne Partials (je eine Komponente).
• Er markiert Komponenten und CMS: data-component="<Komponentenname>" auf dem Root einer Komponenteninstanz (die Nav- und Footer-Partials haben ihre), data-prop="<Eigenschaftsname>" auf dem, was eine Komponenteneigenschaft setzt, data-collection="<Sammlungsname>" auf einem Collection-List-Wrapper und data-field="<Feldname>" auf einem Element, das an ein CMS-Feld gebunden ist (in einem Listenelement oder auf einer CMS-Vorlagenseite). Optisch ändert sich nichts, und sie werden nicht in Webflow erstellt, das seine eigenen Komponenten und CMS-Bindungen hat (prototype-starter/README.md › Komponenten- und CMS-Marker).
• Er liest die Variablen der Website aus einem Snapshot von Webflow (prototype-starter/README.md › Webflow-Snapshot). Nach dem Schreiben oder Aktualisieren des Snapshots: pnpm css, dann pnpm check:snapshot, dann pnpm check:drift, welches den Snapshot mit dem Stylesheet vergleicht, das die Staging-Seite veröffentlicht, und jede Variable, Klasse und jeden Wert auflistet, die abweichen (zuerst auf Staging veröffentlichen).
• Kein Webflow-Connector? (noch nicht eingerichtet, auf einer anderen Website angemeldet, oder kein MCP-Aufruf erlaubt) pnpm css:published <Staging-URL> erstellt tokens.css, webflow.css und webflow-base.css aus dem CSS, das die Website veröffentlicht (nur GET; seitenweises CSS wird Seite für Seite gelesen und zusammengeführt), und stellt den Snapshot so weit wieder her, wie das CSS es zulässt. Das CSS ist exakt; Designer-Namen, Modus-Namen, leere Klassen und Interaktionen sind nicht enthalten (das Skript listet im Header alles auf, was es vermutet). Gib daher in HANDOFF.md an, dass der Snapshot ein Behelf ist, schlage niemals eine Variable oder Klasse unter einem geratenen Namen vor, ohne sie im Designer zu überprüfen, und ersetze den Snapshot über den MCP, sobald dieser verfügbar ist (lösche webflow-snapshot/source.json, dann pnpm css). Solange source.json existiert, weigert sich pnpm css zu laufen.
• Variablenänderungen werden vorgeschlagen, niemals durchgeführt: als alt → neu in proposed.css, gruppiert und mit Buchstaben zur Freigabe. Neue Klassen kommen in new-classes*.css, geschrieben, wie der Designer sie aufnehmen kann.
• Markup wird für den Importer geschrieben: Formen sind divs, keine leeren Spans; Formularsteuerelemente stehen in einem <form>; boolesche Attribute tragen einen Wert; ein Zeilenumbruch hat ein   davor; Module hängen von data-*-Hooks ab, nicht von Klassennamen. pnpm wf:preflight prüft all dies.

Reihenfolge.

1. Snapshot, pnpm css, pnpm check:snapshot, pnpm check:drift (kein Connector: pnpm css:published, dann die gleichen Prüfungen).
2. Der Styleguide (webflow-style-guide-Skill), freigegeben vor jeder Inhaltsseite.
3. Seiten, eine nach der anderen, aus ihren Figma-Frames (webflow-build › Der Prototyp, aus Figma). Für jede: erstelle sie; füge die Zeile für jede Klasse oder Komponente hinzu, die sie eingeführt hat (pnpm style-guide); pnpm screens (jede Breite von 2560 bis 360: Überlauf und Fehler) und pnpm check:states (Fokus- und Gedrückt-Zustände); führe Prototyp-Seite fertig aus; die Person genehmigt sie bei 1440, 820, 667 und 390.
4. Der Kunde genehmigt den Prototyp schriftlich.
5. Die Übergabe (unten).

Übergabe an den Build

Führe Prototyp-Übergabe in checklists.md aus. Das Paket, von dem die Build-Sitzung ausgeht:

• docs/handoff/HANDOFF.md: Seiten, Variablen und Klassen, CMS, zu erstellende Komponenten, Module und ihre Hooks, die Videoliste.
• pnpm wf:styles: jede neue Klasse sortiert danach, was der Connector erstellen kann, was eine Person von Hand im Designer setzt (bereits Zeilen in MANUAL-TODO.md) und was zum Repo-CSS geht.
• pnpm wf:preflight: die bekannten Importer-Schritte pro Seite.
• Der freigegebene Prototyp selbst, laufend, als Referenz, mit der der Build verglichen wird (pnpm wf:compare, wf:pass).

Gib der Person dann die Nachricht, die die Build-Sitzung startet, ausgefüllt, zum Einfügen in eine neue Sitzung, die im Workspace-Ordner geöffnet wird:

Fortsetzung : Build in Webflow. Der Prototyp ist freigegeben (jede Seite und der Styleguide, ). Lies das Workspace-CLAUDE.md, docs/handoff/ und die webflow-build-Skill. Beginne mit der Grundlage: schlage die Variablen-Batch aus proposed.css vor und warte auf mein Go-ahead vor jedem Webflow-Schreibvorgang. Dann tagge Styles, Klassen (aus dem Styles-Plan), CMS-Sammlungen, den Repo-Port und den Loader, die Styleguide-Seite, die Medienseite (falls die Videoliste Einträge hat), Komponenten und Seiten, eine Seite pro Sitzung.

Der Build läuft in seiner eigenen Sitzung, damit nur die Build-Regeln geladen werden und der Prototyp unberührt als Referenz erhalten bleibt.

Arbeitsrhythmus

• Eine Seite pro Sitzung, vollständig abgeschlossen: erstellt, bei jeder Breite geprüft, ihre Zustände erledigt, Prototyp-Seite fertig ausgeführt, Übergabe aktualisiert.
• docs/handoff/ bleibt während der Sitzung aktuell, nicht erst am Ende: Eine Entscheidung wird in HANDOFF.md festgehalten, sobald sie getroffen wird.
• Lektionen zurückgeben. Biete beim Abschluss jede template-candidate-Lektion der Vorlage an (rules.md › Beitragen).