Style Demo Builder

Was macht Style Demo Builder?

Verwandle jedes Produkt in eine schöne Demo-Landingpage, die das visuelle Erscheinungsbild einer Referenz-Website übernimmt – ihre Palette, Typografie, Layoutmuster und Bewegung – während sie die eigene Produktgeschichte des Nutzers erzählt.

Goldene Regel: Kopiere den Stil, niemals den Inhalt. Die Referenzseite liefert das Aussehen; die Seite/das Produkt des Nutzers liefert die Worte. Die Ausgabe darf weder den Text der Referenz reproduzieren noch lediglich das bestehende Layout des Nutzers neu einkleiden – es sollte eine frische Seite im entliehenen Stil sein.

Dies ist der häufigste Fehler. Das Kopieren der Palette der Referenz, aber das Beibehalten des Abschnittsskeletts der eigenen Seite des Nutzers (seine nummerierten Funktionsblöcke, seine Kartenmotive, seine Reihenfolge) erzeugt eine Seite, die immer noch wie die ursprüngliche Seite des Nutzers in neuen Farben wirkt. Umfärben ist nicht Neugestalten. Du musst das Layout-Skelett und die charakteristischen Komponenten der Referenz übernehmen, nicht nur ihre Hex-Werte. Recherchiere immer auch die Struktur der EIGENEN Seite des Nutzers (Schritt 2), damit du weißt, wovon du abweichen musst.

Unterstützte Layout-Muster (wähle pro Anfrage):

• Einzelner entliehener Stil – die gesamte Seite im Look einer Referenz.
• Abschnittsweiser Stil-Rundgang – jeder Abschnitt übernimmt die Identität einer anderen Seite (z.B. Hero → projectdiscovery, Preise → linear, CTA → superhuman). Gib jedem <section> einen eigenen abgegrenzten Theme-Block: Hintergrund, Akzent, Schriftart, Radius und eine charakteristische Komponente. Großartig, wenn der Nutzer sagt „jeder Abschnitt sein eigenes Theme“. Halte sie alle kohärent (z.B. komplett dunkel), es sei denn, der Nutzer wünscht Kontrast.

Toolkit (wird mit dieser Fähigkeit geliefert – nutze es, leite es nicht neu ab)

Pfade sind relativ zu diesem Fähigkeitsverzeichnis. Bevorzuge diese gegenüber dem Schreiben von Grund auf; sie kodieren die unten genannten Fallstricke, sodass du sie nicht erneut triffst.

• template/ – ein baufähiges Next 14 + GSAP + Lenis Grundgerüst mit bereits verdrahteter Bewegungsebene (SmoothScroll, ScrollProgress, Reveal, tokenisiertes globals.css, eine Starter-page.tsx). Jeder Build beginnt hier.
• template-html/index.html – dieselben Tokens + Bewegungsebene als EINE eigenständige Datei (GSAP/Lenis via CDN). Verwende dies, wenn der Nutzer eine einzelne HTML-Datei als Ausgabe wählt; kein Grundgerüst/Installation erforderlich.
• scripts/new-demo.sh <ziel> – Kopiert das Template nach <ziel> und führt npm install aus.
• scripts/verify.sh <verz> – Schritt 5 als Skript: verweigert den Build, während next dev läuft, prüft Typen, baut den statischen Export, durchsucht out/index.html.
• scripts/extract-style.js – Führe es in einer geöffneten Referenzseite über das javascript_tool der Chrome-Entwicklertools aus, um echte Schriftarten/Farben/Radien/Skalierungen in einen Spezifikationsentwurf zu extrahieren (Schritt 2).
• scripts/shoot.mjs <url> – Headless Playwright-Screenshots, nur für Sandboxen/CI ohne Bildschirm. Lokal Screenshots mit den Chrome-Entwicklertools machen.
• scripts/deploy.sh [verz] [--prod] – Verschiebt das gebaute statische Verzeichnis (out/ oder den Ordner der einzelnen HTML-Datei) auf eine Live-URL. Standardmäßig Vercel; da es sich nur um statische Dateien handelt, funktioniert jeder Host. Nach außen gerichtet – zuerst bauen und mit dem Nutzer bestätigen, bevor --prod verwendet wird.
• scripts/audit.sh <url> – Lighthouse-Ergebnisse (Perf/Accessibility/Best-Practices/SEO) gegen einen Dev-Server oder ein Deployment.
• references/patterns.md – Animationsrezepte + Blaupausen für charakteristische Komponenten, ausgewählt nach der Energie der Referenz.

Schritt 1 – Befrage den Nutzer (führe dies zuerst aus)

Verwende das AskUserQuestion-Tool. Stelle diese Fragen zusammen. Die ersten beiden sind Freitext (weise den Nutzer an, sie über das Feld „Sonstiges“ oder im Chat zu beantworten); der Rest sind Multiple-Choice mit sinnvollen Optionen. Füge immer einen „eigene Angabe“-Pfad hinzu.

1. Deine Website / dein Produkt – eine URL (z.B. www.acme.com) oder eine kurze Beschreibung. Dies ist die Inhaltsquelle.
2. Referenz-Website(s) – eine oder mehrere URLs, deren Stil übernommen werden soll (z.B. granola.ai, linear.app, stripe.com). Dies ist die Aussehenquelle.
3. Schriftart-Stil (Mehrfachauswahl) – z.B. Editorial Serif · Saubere Sans-Serif · Monospace/technisch · Abgerundet/freundlich · Der Referenz entsprechend.
4. Theme (optional, Mehrfachauswahl) – z.B. Hell/Papier · Dunkel/filmisch · Kräftiger Farbblock · Minimal/viel Weißraum · Der Referenz entsprechend.

Füge diese zusätzlichen Fragen hinzu (sie verändern das Ergebnis maßgeblich):

5. Stimmung / Ton – Ruhig & redaktionell · Filmisch & dramatisch · Verspielt & optimistisch · Unternehmen & vertrauenswürdig.
6. Bewegungsgrad – Dezent (sanfte Einblendungen) · Reichhaltige Scroll-Animationen (Parallax, scroll-verknüpfte Abschnitte) · Interaktiv (anklickbares Demo, das der Besucher steuert). Standard: Reichhaltige Scroll-Animationen.
7. Akzentfarbe – Der Referenz entsprechend · eine bestimmte Farbe · lass mich wählen.
8. Tiefe – Hero + ein paar Abschnitte · Vollständige Geschichte (alles erzählen: Funktionsweise, Funktionen, Beweise, CTA). Standard: Vollständige Geschichte.
9. Ausgabe – Lauffähiges Next.js-Projekt (empfohlen) · Einzelne eigenständige HTML-Datei.

Wenn der Nutzer in seiner Nachricht bereits einige Antworten geliefert hat, frage diese nicht erneut ab.

Schritt 2 – Recherchiere die Referenz-Website(s)

Du musst die Referenz tatsächlich ansehen, nicht raten.

1. Versuche zuerst mcp__workspace__web_fetch. Marketing-Seiten werden meist clientseitig gerendert, daher gibt es oft leer zurück – das ist zu erwarten.
2. Wechsle zu den Chrome-Browser-Tools (lade bei Bedarf über ToolSearch): navigate → get_page_text für Text/Struktur, dann computer-Screenshots (scrolle nach unten und mache 3–5 Aufnahmen), um die tatsächliche visuelle Sprache zu erfassen. Lehne Cookie-Banner mit der datenschutzfreundlichsten Option ab.
3. Besorge dir günstig einen Beweisentwurf: Füge scripts/extract-style.js über das javascript_tool der Chrome-Entwicklertools auf der geöffneten Referenzseite ein – es gibt echte Schriftarten, Farbhäufigkeiten, die Schriftskala und Radien zurück. Dann schreibe die kurze Stilspezifikation (fülle das Schema in references/style-extraction.md): Hintergrund, Palette + Akzent, Schriftart-Kombination, Abschnitts-/Layout-Muster, charakteristische Komponenten (z.B. schwebende Produkt-Mockups) und Bewegungscharakter. Das Skript erfasst Werte, die das Auge falsch einschätzt; deine Screenshots erfassen Layout und die charakteristischen „verräterischen Details“. Verwende beide.
4. Lies auch die Seite des Nutzers auf die gleiche Weise – für echte Produktinhalte und um ihr eigenes Layout/Skelett, Schriftarten und Footer zu notieren. Du benötigst dies, damit du bewusst davon abweichen kannst (die Struktur der Referenz übernehmen, nicht die des Produkts) und so dass du den echten Footer/Rechtstext des Produkts wörtlich wiederverwenden kannst, anstatt einen zu erfinden.
5. Nicht-lateinische Inhalte: Wenn der Produkttext Devanagari, CJK, Arabisch, Kyrillisch usw. enthält (z.B. eine Hindi + Englisch Code-Switching-Demo), notiere es jetzt – du musst eine Schriftart laden, die diese Schrift abdeckt (siehe Build-Anleitung, Fallstricke).

Wenn eine Domain nicht abgerufen werden kann oder blockiert ist, informiere den Nutzer und fahre mit Screenshots / seiner Beschreibung fort – versuche niemals, die Abrufbeschränkung zu umgehen.

Schritt 3 – Plane

Bilde die Produktinhalte des Nutzers auf die strukturellen Muster der Referenz ab. Erstelle eine kurze Abschnittsgliederung. Wähle Schriftarten (nächste kostenlose Google Fonts zur Referenz), die Palette und den Bewegungsplan. Bestätige alles wirklich Mehrdeutige, dann baue.

Schritt 4 – Baue

Standard-Stack: Next.js 14 (App Router, Static Export) + GSAP ScrollTrigger + Lenis, handgeschriebenes CSS mit Design-Tokens am Anfang von globals.css.

Gerüst aus dem Template – schreibe den Stack nicht von Hand. Führe scripts/new-demo.sh <ziel> aus; es kopiert template/ (Bewegungsebene bereits verdrahtet und bekanntermaßen baubar) und installiert Abhängigkeiten. Dann:

1. Setze die Design-Tokens in app/globals.css :root aus deiner Stilspezifikation und tausche die Schriftarten in app/layout.tsx gegen die passenden Google Fonts aus.
2. Ersetze app/page.tsx mit den echten Abschnitten – die Inhalte des Nutzers, abgebildet auf das Layout-Skelett der Referenz (nicht auf die eigene Seite des Nutzers).
3. Baue die charakteristische Komponente und wähle 2–4 Bewegungsrezepte aus references/patterns.md; references/build-guide.md enthält die Starter für Sticky-Tabs und Mockups. Verwende .rise, [data-speed] und <Reveal> für den Rest.

Wenn der Nutzer eine einzelne HTML-Datei gewählt hat, beginne stattdessen mit template-html/index.html (gleiche Tokens + Bewegungsebene, GSAP/Lenis via CDN, keine Installation) und ersetze seinen Inhalt. Siehe Build-Anleitung, Hinweise zum abschnittsweisen Rundgang für eine Multi-Theme-Variante.

Respektiere immer prefers-reduced-motion. Behalte das Gefühl der Referenz bei, schreibe aber originäres Markup und originale Texte.

Schritt 5 – Verifiziere

Führe scripts/verify.sh <verz> aus – es prüft Typen, baut den statischen Export und durchsucht out/index.html. Füge eigene Greps für den echten Produkttext, den Akzent-Hex und den Schriftartnamen hinzu (das Skript erinnert dich daran). Behebe alles, bis es grün ist.

Sieh dir das Ergebnis an. In einer lokalen Sitzung kannst du es gerendert sehen: Starte npm run dev, richte die Chrome-Entwicklertools auf http://localhost:3000 und mache einen computer-Screenshot (scrolle durch). Dies ist die echte Qualitätskontrolle – führe sie durch, vertraue nicht nur dem Grep. In einer Sandbox ohne Bildschirm, in der localhost nicht erreichbar ist, verwende scripts/shoot.mjs http://localhost:3000 (oder gegen ein Deployment) für headless Screenshots und sage Bescheid, wenn selbst das nicht verfügbar ist.

Führe NIEMALS npm run build aus, während npm run dev läuft. Beide schreiben in .next; der Build überschreibt die Chunks des Dev-Servers während des Flugs und die Seite stirbt mit Error: Cannot find module './31.js' (oder ähnlich). Das hat uns gebissen und sieht wie ein Code-Fehler aus, ist es aber nicht. Während ein Dev-Server läuft:

• Typenprüfung mit npx tsc --noEmit (berührt .next nicht);
• für einen echten npm run build, stoppe zuerst dev;
• wenn der Dev-Server bereits beschädigt ist: pkill -f "next dev", rm -rf .next, dann starte npm run dev neu.

Beim Bearbeiten eines laufenden Dev-Servers, bevorzuge tsc --noEmit + ein curl localhost:3000 | grep für deinen Inhalt, um zu bestätigen, dass es kompiliert wurde, anstatt zu bauen.

Schritt 6 – Verpacke & übergib

Entferne node_modules, .next, out, zip das Projekt und teile es mit mcp__cowork__present_files. Gib die Ausführungsbefehle (npm install && npm run dev) und eine Zusammenfassung von einem Absatz, wie der Stil der Referenz angewendet wurde.

Schritt 7 – Live gehen & überprüfen (optional)

Wenn der Nutzer eine teilbare URL oder eine Qualitätszahl wünscht:

• Überprüfung: scripts/audit.sh http://localhost:3000 (Dev-Server läuft) gibt Lighthouse-Performance/Accessibility/Best-Practices/SEO aus. Ziele auf 90+; Zugänglichkeit und SEO sind die günstigen Gewinne, die vor dem Versand behoben werden sollten.
• Deployment: Baue zuerst (scripts/verify.sh <verz> erzeugt out/), dann scripts/deploy.sh out für eine Vorschau-URL. Das Deployment ist nach außen gerichtet – bestätige mit dem Nutzer vor scripts/deploy.sh out --prod und deploye kein veraltetes out/. Es sind statische Dateien, daher funktioniert Vercel/Netlify/jeder Host.
• Führe audit.sh <deploy-url> erneut gegen die Live-URL aus, um einen Wert im echten Netzwerk zu erhalten.

Leitplanken

• Originalität: Kopiere niemals den Text der Referenz und bette keine Logos oder markenrechtlich geschützten Bild-Assets ein – verwende stattdessen CSS-generierte Texturen/Formen. Firmennamen in einem Vergleich/Wortkontext sind in Ordnung.
• Sensible Bereiche: Wenn das Produkt aus den Bereichen Gesundheit, Finanzen, Recht oder ähnlich ist, halte den Ton verantwortungsvoll und genau, kennzeichne Demodaten als illustrativ, vermeide Garantien und füge angemessene Hinweise ein (z.B. eine Krisenressourcen-Zeile für psychische Gesundheitsseiten). Halte Lade-/Marketing-Sprache nicht alarmierend.
• Illustrative Daten: Weise darauf hin, dass alle gezeigten Namen, Zahlen, Zitate oder Verfügbarkeiten Platzhalter-Demoinhalte sind – aber halte es klein und unauffällig (eine kurze Zeile), niemals einen riesigen Haftungsausschlussblock und niemals in den Footer gequetscht, als wäre es der Footer der Seite. Wenn der Nutzer den echten Footer des Produkts wünscht, repliziere diesen (siehe unten) und platziere den illustrativen Hinweis woanders oder lasse ihn weg, wenn der Nutzer ihn explizit überschreibt – informiere ihn dann, dass nichts mehr die Demodaten als illustrativ kennzeichnet.
• Footer: Bevorzuge den echten Footer des Produkts – rufe ihn ab und verwende seinen Slogan, Links und Copyright wörtlich wieder – anstatt einen zu erfinden oder einen Build-Hinweis dort zu hinterlassen.
• Bewegung: Jede Animation muss unter reduzierter Bewegung elegant degradieren.

Gelernte Fallstricke (NICHT wiederholen)

Schwer erkämpft aus echten Durchläufen. Vollständige technische Details in references/build-guide.md.

1. Umfärben ≠ Neugestalten. Behalte nicht das Abschnittsskelett der eigenen Seite des Nutzers und tausche nur Farben – es sieht immer noch wie sein Original aus. Übernimm die Struktur und charakteristischen Komponenten der Referenz. (Siehe Goldene Regel.)
2. display:flex auf einem Text-Listenpunkt / Absatz, der Inline-Markup (<b>, <span>) enthält, teilt jede Inline-Sequenz in eine eigene Flex-Spalte auf – Text zersplittert in gebrochene Spalten. Verwende ein positioniertes ::before für Aufzählungszeichen; halte Textcontainer auf display:block. Flexe nur den Wrapper, niemals die Textzeile selbst.
3. Führe niemals npm run build aus, während npm run dev läuft (beschädigt .next). Verwende npx tsc --noEmit zur Überprüfung, während der Dev-Server läuft. (Siehe Schritt 5.)
4. Nicht-lateinische Schriften benötigen ihre eigene Webfont. Devanagari/CJK/Arabisch werden in Inter/JetBrains Mono nicht gerendert; lade die passende next/font mit den richtigen subsets (z.B. Noto_Sans_Devanagari, subsets:["devanagari"]) und wende eine .hi{font-family:var(--f-deva)}-Klasse an. Verlasse dich nicht auf OS-Fallback-Schriftarten.
5. Verwende den echten Footer des Produkts wieder, erfinde keinen oder wirf einen Build-Hinweis dort hinein (siehe Footer-Leitplanke).

Qualitätsanspruch

Ziele auf etwas ab, das als echte Launch-Seite durchgehen könnte: selbstbewusste Schriftskala, zurückhaltende Palette, ein charakteristisches visuelles Element von der Referenz und Bewegung, die Inhalte beim Scrollen enthüllt, anstatt sie zu dekorieren. Verwende nicht dasselbe Layout für verschiedene Referenzen – der ganze Sinn ist, dass jedes Ergebnis wie die Seite aussieht, von der es entliehen hat.