Vivelebacon/demo-website

Was macht demo-website?

Ein Durchlauf bringt einen Prospect von „Ja, ich würde es gern sehen“ zu einem Live-Redesign und einer Antwort im Entwurf-Ordner. Der Benutzer gibt eine URL oder einen Namen ein; alles andere wird gefunden, nicht erfragt. Die kreative Leitung ist für den gesamten Durchlauf delegiert: keine Zwischenstopps für Interview-Antworten oder Freigaben.

Referenz-Build: Sobald Sie eine Demo geliefert haben, mit der Sie zufrieden sind, behalten Sie sie als Referenz. Lesen Sie deren BRIEF.md und kopieren Sie deren Struktur (site.css, site.js, pages.css, home.css, home.js, lab/) als Startgerüst. Kopieren Sie niemals das Design: die Fingerabdruck-Sperre verbietet es.

Feste Regeln für jede Demo

• Behalten: das Logo, jedes Foto, jedes Wort des Textes, jede Seite und die Reihenfolge der Abschnitte innerhalb jeder Seite. Tippfehler bleiben. Navigationsbeschriftungen bleiben. CTA-Beschriftungen bleiben.
• Ändern: alles Visuelle. Layout, Schriftart, Farbverwendung, Bewegung, Interaktion.
• Jede Seite wird neu gestaltet, nicht nur die Startseite. Eine HTML-Datei pro Originalseite, gleiche Slugs (cleanUrls hält /services funktionsfähig).
• Erlaubte Ergänzungen: nur minimale UI-Mikro-Texte (Statuszeilen für Formulare, ein Platzhalter in Eingabefeldern, aria-Labels). Keine neuen Marketingtexte, keine erfundenen Zahlen.
• Hausregeln gewinnen über jede Referenz (bearbeiten Sie diese Liste nach Ihrem Geschmack): helle Palette mit dem eigenen Akzent des Kunden, Marke + Inhaberfoto + alle Dienstleistungen im Hero sichtbar, Sticky-Header immer sichtbar, Logo-Klick führt zurück nach oben (sanftes Scrollen auf der Startseite), keine Seitenleiste, keine Gedankenstriche sichtbar, nur eigene Fotos des Kunden (keine Generierung, außer der Benutzer bittet darum).
• Auf Vercel Production deployen und ohne Nachfrage committen. E-Mails sind nur Entwürfe.

Schritt 0 · Den Prospect identifizieren

1. Wenn der Benutzer einen Namen statt einer URL angibt und Sie ein CRM führen: schlagen Sie den Prospect dort nach Website, Stadt, Sprache, dem Postfach, von dem die Kontaktaufnahme ausging, und dem Antwortstatus nach. Wenn der Prospect nicht in einem CRM ist, arbeiten Sie von der URL und fragen Sie nichts; der Entwurf-Schritt wird sagen, welches Postfach benötigt wird.
2. Slug: der Domain-Stamm, z. B. acmecoaching. Build-Ordner: demos/<slug>-scrollcraft/. Vercel-Projekt: <slug>-redesign. Demo-URL: https://<slug>-redesign.vercel.app (Bindestrich, niemals Punkt: eine gepunktete Subdomain existiert nicht, und ein toter Link ist der teuerste Fehler in dieser Pipeline).
3. Vorname für die E-Mail: aus der E-Mail-Signatur des Prospects, der Über-uns/Kontakt-Seite der Website oder der Domain („janecoaching“ → Jane). Wenn wirklich unbekannt, weglassen („Bonjour,“ / „Hallo,“).

Schritt 1 · Die gesamte bestehende Website erfassen

Alles geht nach <build>/_src/ (Roh-Assets) und <build>/lab/ (Notizen, Screenshots).

1. Die Startseite abrufen und die Nav- + Footer-Links lesen, um jede Seite aufzulisten. Jede Seite abrufen.
2. Pro Seite in Reihenfolge extrahieren: Abschnitte, Überschriften, Absätze (mit fett/kursiv-Spannen), Listen, Buttons und deren Ziele, Bilder (Vollauflösungs-URLs; für Squarespace ?format=2500w anhängen, für Wix den /v1/fill/...-Transform strippen), Formulare (Feldbezeichnungen, Pflichtfelder, Submit-Label, Erfolgsmeldung), eingebettete Videos. Squarespace speichert Formulardefinitionen in data-block-json / formFields.
3. Das Logo (alle Varianten: dunkel, hell, Favicon), jedes Foto, jede Textur herunterladen. Ein einfaches geometrisches Logo mit cv2.findContours + approxPolyDP auf seinem Alphakanal zu SVG vektorisieren; das PNG für komplexe Marken behalten.
4. Marken-Token: Akzent/Tinte/Hintergrund aus den CSS-Variablen der Website, Überschrift- und Textschriften. Die nächste Google-Schriftart wählen, wenn die Schriftart Typekit oder benutzerdefiniert ist.
5. Vollseiten-Screenshots jeder Live-Seite (scripts/full.mjs <live-url> 1440 900 lab/live <seiten>) und diese lesen: das ist die Struktur, die Sie behalten müssen.

Schritt 2 · Mit scroll-craft gestalten

Laden Sie Ihr Design-Recherche-Skill, falls Sie eines haben, dann scroll-craft (https://github.com/nateherkai/scroll-craft), und folgen Sie scroll-craft von Anfang bis Ende mit diesen Überschreibungen:

• Das Briefing ist selbst verfasst unter ausdrücklicher kreativer Delegation (die ständige Anweisung des Benutzers ist dieses Skill). Schreiben Sie BRIEF.md mit: den obigen festen Regeln, den Erkenntnissen aus Schritt 1, den acht verfassten Themen, einer benannten Grammatik mit echten Einschränkungen, der Gefühlskurve, dem einen Höhepunkt, dem „Sag-es-jemandem“-Satz, dem Signature-Move, der Bewertungstabelle und einem kurzen Plan für jede innere Seite.
• Führen Sie die Fingerabdruck-Sperre gegen Ihren scroll-craft-Arbeitsbereich FINGERPRINTS.md aus (4 von 6 gegen jede Zeile). Lesen Sie die Zeile „Was der nächste Build vermeiden muss“ jeder aktuellen Zeile. Der Signature-Move muss von dieser Marke stammen (ihre Logo-Geometrie, ihr Slogan, ihr eigenes Foto), nicht vom letzten Build.
• Die Struktur wird vom Kunden festgelegt, daher ändern die Grammatik und die Vorrichtungen, wie sich dieselben Abschnitte verhalten, niemals, welche Abschnitte existieren.
• Vanilla-Engine (scrollcraft.js/.css unverändert kopiert), einfaches Multi-Page-HTML, seitenlokales JS für maßgeschneiderte Szenen.

Schritt 3 · Bauen

• Gemeinsam: site.css (Tokens, Header, Menü, Footer, Buttons, Rahmen, Eingänge), site.js (mountet die Engine, Header-Zustand, Menü, Logo-nach-oben, Eingänge, Formular), pages.css für innere Seiten, home.css/home.js für die maßgeschneiderten Szenen der Startseite.
• Das Gerüst für innere Seiten aus einem Einmal-Skript ist in Ordnung; danach sind die HTML-Dateien die Quelle. Sagen Sie das in BRIEF.md.
• Kontaktformulare: mailto:-Übergabe an die Adresse des Kunden mit method="post", Validierung und einer Statuszeile, die klar sagt, dass die Mail-App geöffnet wird und nichts gesendet wird, bis der Benutzer auf Senden drückt. Niemals einen Erfolg vortäuschen.
• Shops und Buchungstools: Links zu den bestehenden Produkt-/Buchungsseiten des Kunden.

Fallstricke, die bereits eine Runde gekostet haben

• Niemals position auf einem [data-sc-stage]-Element setzen. Die Engine macht es sticky; position: relative in Ihrem CSS tötet leise jeden Pin.
• Der Höhepunkt muss den größten data-sc-span auf der Seite behalten. Wenn der Hero wächst, wachsen Sie den Höhepunkt mit.
• Geschichteter Hero aus einem Foto: jede Silhouette mit einem DP-Kantenpfad nachzeichnen (zuerst grober Gradient, dann auf dem feinen verfeinern), jede Platte unter der nächsten Silhouette neu aufbauen (Himmel: angepasster vertikaler Gradient; entfernte Dunstschicht: flache, spaltenweise Farbe; texturierte Hänge: Spiegelkachel ~110px), übrig gebliebene dunkle Punkte über den nachgezeichneten Linien entfernen, dann die endgültige Scroll-Position betrachten: Nähte zeigen sich nur am Ende der Bewegung.
• Personenausschnitte: rembg u2net_human_seg, die Maske um ~2px erodieren und Randfarben dekontaminieren, sonst zeigt sich die ursprüngliche Wand als Halo. Zuschneiden, wo eine Vordergrundebene oder ein Basisband den Ausschnitt verdeckt.
• Alles mit white-space: nowrap in einem Grid bricht auf Telefon-Layouts; Buttons unter 520px umbrechen lassen und minmax(0, 1fr) verwenden.
• Gekippte dekorative Blöcke überlaufen auf Telefonen den Viewport: overflow-x: clip auf deren Abschnitt.
• Ein ersetztes Bild behält auf Telefonen eine Woche lang seine alten Bytes (/assets-Cache-Header): neue Grafiken bekommen einen neuen Dateinamen (-v2).
• .prose p { margin: 0 } schlägt .prose > * + *; schreiben Sie die Abstandsregel als .prose > * { margin: 0 } .prose > * + * { margin-top }.

Schritt 4 · Verifizieren

Lokal bereitstellen (node <scroll-craft>/scripts/serve.mjs --root . --port 4610) und scripts/snap.mjs / scripts/full.mjs aus diesem Skill verwenden. Beide lösen playwright-core aus dem Ordner auf, in dem Sie sie ausführen, oder einem beliebigen übergeordneten Ordner, daher deckt ein npm i playwright-core im Projektstamm jeden Build darunter ab.

• Desktop 1440x900 an mehreren Positionen innerhalb jedes gepinnten Akts, Telefon 390x844 und 360x640, reduzierte Bewegung. Jedes Blatt lesen; korrigieren und neu aufnehmen.
• Vollseiten-Aufnahmen jeder inneren Seite bei 1440 und 390: kein Überlauf, kein abgeschnittener Text, keine leeren Grid-Zellen.
• scroll-craft-Harness: kein totes Scrollen, keine Konsolenfehler, keine fehlgeschlagenen Anfragen.
• Kontrast von Text über Bildmaterial gemessen auf zusammengesetzten Pixeln (Text ausblenden, Pixel darunter lesen); Fließtext 4,5:1, großer Text 3:1.
• Funktionell: die Signature-Interaktion von Anfang bis Ende, Formular-Validierungsmeldungen, Menü öffnen/Escape/Fokus, Logo nach oben, Anker der Hero-Dienstleistungen.
• Suchen Sie den Build nach em- und en-Dashes (U+2014, U+2013) durch: null sichtbar.

Schritt 5 · Ausliefern

1. vercel.json: cleanUrls, buildCommand: null, outputDirectory: ".", 7-Tage-Cache auf /assets. .vercelignore: lab/ _src/ node_modules/ BRIEF.md.
2. vercel link --yes --project <slug>-redesign dann vercel deploy --prod --yes.
3. Rauchtest der exakten URL, die Sie senden werden: jede Seite 200, Schlüssel-Assets 200, lab/ und BRIEF.md 404, ein Live-Browser-Load ohne Konsolenfehler.
4. Git-Repo im Build (git init -b main), Commit mit -F <file> (niemals ein PowerShell-Here-String), gh repo create <github-user>/<slug>-redesign --private --source . --push, vercel git connect --yes. Spätere Änderungen: Commit und Push auf main, was neu deployed. Halten Sie das Demo-Repo privat: es enthält das Logo, die Fotos und die Texte des Prospects.
5. Die Fingerabdruck-Zeile an Ihren Arbeitsbereich FINGERPRINTS.md anhängen (alle sechs Dimensionen, Welt, Port, Palette, Schriftart, was es teilt, was der nächste Build vermeiden muss).

Schritt 6 · Den Entwurf verfassen

python scripts/draft_demo_reply.py <prospect-email> --mailbox <alias> --url https://<slug>-redesign.vercel.app --first-name <FirstName>

Es prüft die URL-Antworten, findet die neueste E-Mail des Prospects im Outreach-Postfach, rendert die „Hier ist die Demo“-Vorlage in der Sprache des Kontakts (--lang fr|en) mit der Signatur dieses Postfachs, speichert einen verknüpften Entwurf im Entwurf-Ordner dieses Postfachs und liest ihn zurück. Es sendet niemals. Führen Sie es zuerst mit --dry-run aus, wenn etwas am Thread ungewöhnlich aussieht. Postfächer werden in .env konfiguriert (siehe .env.example).

Wenn der Prospect von einer anderen Adresse geantwortet hat als der, an die Sie geschrieben haben (ein persönliches Postfach statt info@), übergeben Sie sie mit --to <ihre-adresse>: Die Antwort wird von diesem Absender aus nachgeschlagen und der Entwurf geht dorthin. Einige IMAP-Server gleichen eine FROM-Suche nur auf die vollständige Adresse ab; ein Domain-Fragment gibt nichts zurück.

Mit einem verbundenen CRM (DEMO_CRM_DIR, siehe die README) kann <prospect-email> alles sein, was das CRM auflöst, Postfach und Sprache stammen vom Kontakt, und das Skript protokolliert die Antwort des Prospects und die Demo-URL.

Zeigen Sie den Entwurfstext in der endgültigen Nachricht an. Sagen Sie dem Benutzer, er solle Bescheid geben, wenn es gesendet wurde, damit die Demo als gesendet markiert werden kann.

Abschlussbericht (kurz)

Live-URL (die exakte) · neu gebaute Seiten · die Design-Idee in zwei Zeilen · der Signature-Move in einer · die wenigen Mikro-Text-Ergänzungen · was verifiziert wurde und was nicht (echtes Telefon, Safari) · der Entwurf (Postfach, Thread, vollständiger Text) · lokaler Pfad des Build-Ordners.