biplineX/figma-landing

Figma → Landingpage auf HTML/CSS/JS

Dieser Skill übersetzt ein Figma-Design einer Landingpage in statisches HTML, CSS und JS. Die Arbeit erfolgt Block für Block: Nach jedem Abschnitt stoppt der Agent und wartet auf die Bestätigung des Benutzers.

Die Regeln für den Code (Struktur, BEM, Einheiten, Bilder, Hover usw.) befinden sich in der templates/AGENTS.md-Datei dieses Skills. In Schritt 3 wird diese Datei in das Projektstammverzeichnis kopiert und gilt ab dann immer.

Anforderungen

• Der Figma MCP muss angeschlossen sein (get_metadata, get_design_context, get_screenshot, falls vorhanden auch get_variable_defs). Ist er nicht angeschlossen, teile dies dem Benutzer mit und stoppe.
• Der Benutzer hat einen Link im Format https://www.figma.com/design/:fileKey/:fileName?node-id=1-2 bereitgestellt.
• Für den Server, Screenshots und WebP wird Node.js benötigt. Bei npx-Befehlen werden beim ersten Ausführen Pakete aus dem Netz geladen – Codex kann um Erlaubnis fragen, das ist normal.

Arbeitsablauf

Führe die Schritte der Reihe nach aus, ohne einen auszulassen.

Schritt 1. Link analysieren

• fileKey – der Teil nach /design/. Wenn der Link einen Teil /branch/:branchKey/ enthält, verwende branchKey.
• nodeId – der Wert von node-id, ersetze den Bindestrich durch einen Doppelpunkt (1-2 → 1:2).
• Der Link kann auf das gesamte Dokument, eine Seite, einen Desktop-Frame oder einen Mobil-Frame verweisen. Der Typ wird in Schritt 2 bestimmt.

Schritt 2. Layout-Karte

1. Rufe get_metadata für den Knoten aus dem Link auf (für das gesamte Dokument – ohne node-id oder mit der Startseite).
2. Suche nach Frame-Versionen der Landingpage: Desktop, Mobil, manchmal Tablet. Ermittle die Breiten aus dem Layout, setze keine Standardbreiten ein. Finde auch separat liegende Frames für modale Fenster (Popups) und das geöffnete mobile Menü, falls sie auf der Seite vorhanden sind.
3. Hebe innerhalb jedes Frames die oberen Abschnitte hervor (Kopfzeile, Hero, Vorteile, Testimonials, Footer usw.).
4. Ordne die Abschnitte zwischen den Versionen einander zu: „Desktop-Abschnitt ↔ Mobile-Abschnitt“ (anhand des Layer-Namens, der Reihenfolge und des Inhalts).
5. Zeige dem Benutzer die Karte und warte auf Bestätigung:

Breiten: Desktop 1440, Mobil 375
1. header      – 12:30 ↔ 40:2
2. hero        – 12:45 ↔ 40:18
3. advantages  – 13:10 ↔ 41:5
...
Modale Fenster / Menü:
- mobile-menu  – 45:12
- popup-order  – 46:01

Wenn es keine mobile Version gibt, teile dies dem Benutzer mit und frage ihn, wie vorgegangen werden soll.

Schritt 3. Projektgerüst und Basis-UI

1. Wenn im Stammverzeichnis des Projekts keine AGENTS.md vorhanden ist, kopiere templates/AGENTS.md aus dem Skill-Ordner. Fülle darin den Abschnitt „Diese Landingpage“ (Breiten, Container, Schriften) mit den Daten aus Schritt 2 aus. Lasse die Breakpoints unverändert; ändere sie nur, wenn die Umsetzung dieses Layouts bei anderen Breiten bricht – und notiere dann die neuen Werte.
2. Erstelle die Struktur: index.html, style.css, script.js, assets/icons/.
3. index.html: <!doctype html>, lang="de", charset, viewport, <title> und <meta name="description"> sinngemäß zur Landingpage. Füge kein Favicon hinzu. script.js wird mit defer eingebunden.
4. Schriftarten: Entnimm sie aus get_design_context/get_variable_defs, binde sie über Google Fonts nur mit den benötigten Schriftschnitten ein, display=swap. Wenn die Schriftart nicht in Google Fonts vorhanden ist, bitte den Benutzer um die Dateien und binde sie per @font-face aus assets/fonts/ ein.
5. style.css: Style-Reset (siehe AGENTS.md), dann :root mit CSS-Variablen für Farben, Schriftarten, Abstände, Containerbreite. Nimm die Werte aus get_variable_defs, falls im Layout Variablen vorhanden sind; sonst ermittle sie aus dem Layout und runde sie.
6. Basis-Komponenten: Hebe übergreifende Layoutelemente (Buttons, Abschnittsüberschriften, Eingabefelder) in wiederverwendbare Klassen hervor (.btn, .section-title, .input, .container). Wenn das Layout kein UI-Kit mit Zuständen (hover, focus, active) enthält, frage den Benutzer einmalig nach den Regeln für Hover-Effekte bei typischen Buttons und Links für das gesamte Projekt. Notiere die Antwort in der Zeile „UI-Zustände“ des Abschnitts „Diese Landingpage“ in der AGENTS.md.
7. Tools (einmalig):
   • Starte im Hintergrund einen lokalen Server im Stammverzeichnis des Projekts: npx -y serve -l 3000 (Alternative: python3 -m http.server 3000). Alle Screenshots werden von http://localhost:3000 aufgenommen, nicht von file://.
   • Prüfe, wie Screenshots gemacht werden: Playwright MCP, falls angeschlossen; sonst das Skript scripts/shot.cjs (siehe „Selbstprüfung“).
   • Prüfe den Bildkonverter (siehe „Bilder“) und merke dir das Ergebnis.
8. Teile dem Benutzer mit, dass das Gerüst fertig ist, und fahre mit dem ersten Block fort.

Schritt 4. Blöcke einzeln

Für jeden Abschnitt aus der Karte, streng von oben nach unten (einschließlich Abschnitte mit Formularen):

1. Daten. Rufe get_design_context und get_screenshot für den Desktop-Abschnitt und sein mobiles Pendant auf.
   • Wenn die Antwort abgeschnitten oder zu groß ist, rufe get_metadata für den Abschnitt auf und hole die untergeordneten Knoten einzeln.
   • Der Code aus der Antwort (normalerweise React + Tailwind) dient nur als Referenz für Größen, Farben und Struktur. Kopiere nicht seinen Stil.
2. Bilder. Lade die Assets des Blocks herunter und verarbeite sie (siehe „Bilder“).
3. Umsetzung. HTML des Blocks in index.html, Styles in style.css in einem separaten Abschnitt mit Kommentar /* ===== hero ===== */, JS (falls nötig) in script.js. Verwende die Basis-Klassen aus Schritt 3.6, ohne Button- und Überschriften-Code zu duplizieren. Zuerst Desktop, dann responsive bis zur Mobilbreite mit clamp() und Media-Queries.
   • Wichtig: Für den header auf Mobilbreite sofort ein Burger-Menü umsetzen (gemäß dem Frame aus der Karte oder nach Rückfrage beim Benutzer über die Art).
   • Wenn der Block ein Formular enthält, setze es mit den nativen Browser-Validierungsattributen um (required, type="email", type="tel", pattern), aber ohne JavaScript-Sendelogik.
4. Selbstprüfung. Mache Screenshots nur vom aktuellen Abschnitt bei Desktop-, Mobil- und Zwischenbreiten (1024, 768). Vergleiche sie mit den Figma-Screenshots: Abstände, Größen, Schriftarten, Farben, Umbrüche. Korrigiere gefundene Abweichungen und mache neue Screenshots.
   • Über Playwright MCP: Screenshot des Abschnitts-Elements bei jeder Breite.
   • Ohne MCP: Das Skript aus dem Skill-Ordner:

     # einmalig
     mkdir -p .screens && cp <skillordner>/scripts/shot.cjs .screens/
     npm i playwright --prefix .screens && npx -y playwright install chromium
     # nach jedem Block
     node .screens/shot.cjs http://localhost:3000 .hero 1440,1024,768,375
     

     Das Skript speichert .screens/<abschnitt>-<breite>.png und gibt ⚠ horizontaler Scroll aus, wenn die Seite breiter als der Bildschirm ist. Jede solche Warnung muss korrigiert werden (Ursache beheben, nicht durch overflow: hidden am body verstecken).
   • Lösche die Abschnitts-Screenshots nach Bestätigung des Blocks; das Skript selbst und node_modules in .screens/ bleiben bis Schritt 6 erhalten.
5. Bericht und Stopp. Gib dem Benutzer eine kurze Zusammenfassung: was gemacht wurde, wo es Abweichungen vom Layout gab und warum, was bei einzigartigen interaktiven Elementen des Blocks geklärt werden muss (ungewöhnlicher Hover bei Karten, Slider-Parameter). Warte auf Bestätigung. Nimm Korrekturen des Benutzers im selben Block vor, warte dann erneut.
6. Erst nach „ok“ – zum nächsten Block.

Schritt 5. Modale Fenster und Formularlogik

Nachdem alle Hauptabschnitte umgesetzt sind:

1. Setze die versteckten modalen Fenster (Popups) um, falls sie in Schritt 2 gefunden wurden, und füge die Öffnungs-/Schließ-Trigger hinzu (Buttons, Esc, Klick auf Overlay). Das Verhalten richtet sich nach dem Abschnitt „JavaScript“ in der AGENTS.md.
2. Jedes Fenster als separaten Block: Selbstprüfung mit Screenshots im geöffneten Zustand, Bericht und Warten auf Bestätigung.
3. Überprüfe die Funktionalität aller Formulare auf der Seite. Sende keine Daten (fetch/AJAX) irgendwohin, solange der Benutzer es nicht selbst verlangt und eine Adresse (Endpoint) oder eine Spezifikation bereitstellt.

Schritt 6. Finale

Nach Bestätigung des letzten Schritts: Überprüfe die gesamte Seite auf allen Breiten, lösche temporäre Dateien und Ordner (assets/_raw/, .screens/ vollständig), stoppe den Hintergrund-Server, entferne ungenutzte Styles und Bilder. Gib eine kurze Zusammenfassung.

Bilder

1. Hole die Assets des Blocks aus der Figma-MCP-Antwort (Bild-URLs in get_design_context). Wenn eine localhost-Adresse zurückgegeben wird, lade sie direkt herunter. Verwende keine Platzhalter oder externe Icon-Sets.
2. Lade sie in ein temporäres assets/_raw/<block>/ herunter, Rasterbilder in doppelter Größe (2x) ihrer Platzierung im Layout.
3. Responsive Grafik: Wenn in der mobilen Version des Blocks ein beschnittenes (andere Proportionen) oder inhaltlich anderes Bild verwendet wird, lade beide Versionen herunter (hero-bg-desktop.webp und hero-bg-mobile.webp) und binde sie über <picture> ein.
4. Sortierung:
   • Kleine Icons innerhalb interaktiver Elemente (Buttons, Links), die bei Hover die Farbe (fill/stroke) ändern sollen → Inline <svg> in HTML mit fill="currentColor" (oder über CSS mask-image).
   • Statische Icons, Logos, einfache Grafiken → SVG in assets/icons/ über <img> (oder im Block-Ordner, falls es eine große Grafik ist). Wenn das Icon als Rastergrafik geliefert wird, teile dies dem Benutzer mit.
   • Fotos und komplexe Bilder → WebP in assets/<block>/.
5. Konvertierung nach WebP, Qualität 80. Reihenfolge der Versuche:
   1. npx -y sharp-cli -i in.png -o out.webp -f webp -q 80 (benötigt Node.js);
   2. cwebp -q 80 in.png -o out.webp;
   3. nichts vorhanden – behalte das ursprüngliche Format bei und teile dem Benutzer einmal mit, was installiert werden sollte (Node.js oder cwebp), ohne die Arbeit zu stoppen.
6. Wenn WebP schwerer als das Original ist, behalte das Original.
7. Dateinamen: Lateinisch, Kleinbuchstaben, mit Bindestrich, sinngemäß (hero-photo.webp, arrow-right.svg).
8. Lösche nach Bestätigung des Blocks assets/_raw/<block>/.

Hover, Animationen, Slider

• Hover: Für Basis-Buttons und Links gelten die Regeln aus der Zeile „UI-Zustände“ in der AGENTS.md. Wenn der Block einzigartige interaktive Karten/Elemente ohne Zustände im Layout enthält, erfinde sie nicht, sondern frage den Benutzer im Blockbericht.
• Scroll-Animationen und benutzerdefinierte Animationen – nur wenn der Benutzer ausdrücklich darum bittet. Kläre zuerst, was genau passieren soll. Einfache Animationen (Erscheinen beim Scrollen) – IntersectionObserver; aufwändige (Radbindung, „klebende“ Abschnitte, Parallaxe) – GSAP per CDN, nur nach Zustimmung des Benutzers. Berücksichtige immer prefers-reduced-motion.
• Slider: Einfacher (Pfeile, Punkte, Wischen) – eigener mit CSS scroll-snap + wenig JS. Komplexer (endlos, Autoplay, Effekte, verbundene Slider) – Swiper per CDN.

Häufige Probleme

• Figma-Antwort abgeschnitten → Rufe get_metadata für den Abschnitt auf, dann get_design_context für die untergeordneten Knoten.
• Mobiles Gegenstück eines Abschnitts oder mobiler Menü-Frame nicht sichtbar → Frage den Benutzer, erfinde nichts.
• Schriftart stimmt nicht mit der Layoutbreite überein → Überprüfe den Schriftschnitt und letter-spacing, passe die Schriftgröße nicht an.
• Bilder werden nicht heruntergeladen → Überprüfe, ob der Figma MCP läuft; verwende die Links unverändert.
• Schriftarten oder Symbole fehlen im Screenshot → Überprüfe, ob der Server auf localhost:3000 läuft und der Screenshot von ihm und nicht von file:// aufgenommen wird.
• Das Skript meldet „horizontalen Scroll“ → Finde das Element, das breiter als der Bildschirm ist (feste Breite, großer gap, Dekoration am Rand) und korrigiere es; für dekorative Elemente am Rand verwende overflow-x: clip auf ihrem Abschnitt.
• Abweichung vom Layout aus Gründen der Barrierefreiheit oder technischer Einschränkungen → Zulässig, aber im Blockbericht erwähnen.