Landing Page Builder

Erstelle qualitativ hochwertige, bereitstellungsfertige Landing Pages, indem du Branding und Inhalte aus Kundenwebsites und -dokumenten extrahierst und eine responsive HTML/CSS-Seite mit verifizierten Bildern und sauberer Struktur produzierst.

Dieser Skill existiert, weil Landing Pages eine sorgfältige Koordination von Branding, Inhalten, Bildern und responsivem Design erfordern – und der häufigste Fehler ist es, Quelldokumente als reine Textdokumente zu behandeln und dabei die Bilder zu übersehen, die die Hälfte der Marketingbotschaft tragen.

Die Goldenen Regeln

1. Bilder sind Inhalt, keine Dekoration. Wenn ein Marketing-PDF neben einem Absatz über das Wohlbefinden von Schülern ein Klassenfoto zeigt, IST dieses Foto die Botschaft. Eine Landing Page ohne diese Bilder ist unvollständig, egal wie gut der Text ist. Extrahiere und integriere Bilder im ersten Durchlauf, jedes Mal.

2. Halte das Styling innerhalb des gewählten Stacks wartbar. Verwende für eine statische Seite CSS in styles.css, nicht inline im HTML. Für ein bestehendes Framework-Projekt, behalte dessen etablierte CSS-Module, Komponentenstile, Utility-Klassen oder Token-System bei. Migriere keine Styling-Architektur ohne Grund.

3. Erfinde niemals Inhalte. Verwende nur das, was das Quelldokument bereitstellt. Erfinde keine Bildunterschriften, visuelle Anweisungen, Testimonial-Zitate, Statistiken oder Kundennamen. Wenn Inhalte fehlen, markiere es und frage nach – fülle Lücken nicht mit KI-generierten Platzhaltertexten.

4. Verwende den Frontend-Stack bewusst. Lade vor dem Programmieren die verfügbaren unterstützenden Skills, die unten genannt werden. Sie sind komplementäre Rollen, keine doppelten Anweisungen, die blind zusammengefügt werden sollen. Wenn ein benannter Skill nicht verfügbar ist, fahre mit dem verfügbaren Stack fort und notiere die Lücke; täusche niemals vor, dass er ausgeführt wurde.

Frontend Skill Stack (Erforderliches Routing)

Die per Screenshot bereitgestellten Frontend-Tools ordnen sich diesem Landing-Page-Workflow wie folgt zu. Lies references/frontend-skill-stack.md für die vollständigen Routing- und Konfliktregeln.

frontend-design – Erstelle die themenspezifische visuelle These, Typografie, Palette, Layout-Konzept, Signatur-Element und Bewegungsabsicht. Verwende es für Neubauten und sinnvolle visuelle Umgestaltungen.
design-taste-frontend – Wende Anti-Slop-Implementierungsdisziplin, responsive Layout-Mechaniken, zugängliche Interaktionszustände, Komponentenauswahl, Leistungsprüfungen und den endgültigen Design-Check vor dem Flug an.
imagegen-frontend-web – Verwende es, wenn generierte visuelle Referenzen die Unklarheit wesentlich reduzieren würden: unbekannte visuelle Richtung, bildgeführte Kampagnen, individuelle Illustration/künstlerische Leitung oder ein Benutzer, der nach Mockups fragt. Es generiert Referenzen; es ersetzt keine echten Marken-Assets oder die Implementierung.
design-taste-frontend-v1 – Nur Legacy-Fallback. Verwende es, wenn ein bestehendes Projekt explizit von v1-Verhalten abhängt; lade v1 und aktuelles Design Taste nicht zusammen.
imagegen-frontend-mobile – Nicht Teil eines Website-Landing-Page-Baus. Verwende es nur für ein separates mobiles App-Bildschirm-Lieferobjekt, niemals als Schritt des responsiven Webdesigns der Seite.
Aidesigner Frontend – Wenn dieser genaue Skill installiert und auffindbar wird, verwende ihn als optionale zweite Kritik der genehmigten künstlerischen Leitung. Er wird derzeit nicht als verfügbar angenommen und darf den Workflow niemals blockieren.

Führe nicht jedes Tool aus Zeremoniell aus. Der minimale Stack für eine neue Landing Page ist frontend-design + aktuelles design-taste-frontend + landing-page. Füge imagegen-frontend-web hinzu, wenn die Generierung visueller Referenzen gerechtfertigt ist. Responsives mobiles Web bleibt Teil der Implementierung und QA; es wird nicht an den mobilen App-Bild-Skill delegiert.

Erforderliches Design-Gate vor dem Code

Erstelle vor der Implementierung ein internes Build-Briefing, das Folgendes enthält:

Zielgruppe der Seite, einziges Conversion-Ziel und Quelle-der-Wahrheit-Inhalt;
eine kohärente visuelle These, die mit dem tatsächlichen Thema verbunden ist, nicht mit einer generischen SaaS-Ästhetik;
Palette und Typografie-Rollen mit überprüfter Lizenzierung/Verfügbarkeit;
Abschnittsreihenfolge und die Aufgabe jedes Abschnitts;
Asset-Karte: erhalten, beschaffen, generieren oder weglassen;
eine signifikante visuelle Idee und einen zurückhaltenden Bewegungsplan;
Desktop-, Tablet- und Mobilverhalten für den ersten Faltbereich und komplexe Abschnitte;
explizite Vermeidungsliste basierend auf dem Marken- und Referenz-Audit.

Wenn der Benutzer eine Referenz bereitgestellt hat, extrahiere Prinzipien, ohne deren Identität zu kopieren. Wenn die Quelle eine bestehende Kundenseite oder eine genehmigte Vorlage ist, behalte genehmigte Texte, Marken-Assets, Komponenten-Grammatik und Abschnittsreihenfolge bei, es sei denn, der Benutzer autorisiert ausdrücklich ein Redesign.

Anti-Slop-Regeln (VERPFLICHTEND)

Diese Muster lassen KI-generierte Seiten billig und generisch aussehen. Verwende sie NIEMALS:

Verbotene Textmuster

„Revolutionieren“, „Transformieren Sie Ihre“, „Entfesseln Sie die Kraft von“, „Nutzen Sie“, „Befähigen Sie“
„Modernste“, „Nächste Generation“, „State-of-the-Art“, „Best-in-Class“
„Nahtlos“, „Mühelos“, „Supercharged“
„In der heutigen schnelllebigen Welt“, „In einer Ära von“
Absätze mit „Stellen Sie sich vor...“ oder „Stellen Sie sich Folgendes vor...“ beginnen
Generische CTAs wie „Mehr erfahren“ oder „Jetzt starten“ ohne Kontext – verwende spezifische CTAs: „Sofortiges Angebot erhalten“, „Demo buchen“, „Preise ansehen“

Verbotene visuelle Muster

Verlaufnetzblobs oder Aurora-Hintergründe (das #1 Erkennungszeichen KI-generierter Seiten)
Lila-zu-Blau-Verläufe als primäre Designsprache
Schwebende 3D-Objekte ohne Verbindung zum Produkt
Generische abstrakte geometrische Muster als Heldenhintergründe
Übermäßig abgerundete Karten (border-radius > 1.5rem) mit starken Schlagschatten
Identische Kartenlayouts, die 3+ Mal mit nur Icon-Änderungen wiederholt werden
Stock-Foto-Heldenbilder, die nicht zum Geschäft passen (z.B. generische Händeschüttelfotos)

Verbotene Codemuster

Inline-Stile in HTML-Elementen
Verwendung von !important in CSS (außer für Utility-Overrides)
Hartcodierte Pixelwerte für Schriftgrößen – verwende clamp() oder rem
Fehlende alt-Attribute für Bilder
Verwendung von <div>, wenn semantische Elemente existieren (<section>, <article>, <nav>, <header>, <footer>)

Arbeitsablauf-Übersicht

Der Build folgt sieben Phasen. Kläre offensichtliche Fakten aus den gelieferten Quellen, anstatt den Benutzer zu bitten, sie zu wiederholen. Frage nur, wenn eine fehlende Entscheidung das Ergebnis wesentlich verändert.

Kontext & Recherche – Lies Projekt-/Kundenanweisungen, Meeting-Entscheidungen, Briefing, Genehmigungsstatus, Live-Marke, Referenzen, Texte und Design-Grammatik
Content-Extraktion – Extrahiere alle genehmigten Texte und Bilder aus den gelieferten Quellen
Asset-Verifizierung – Erstelle ein herkunftsbasiertes Inventar verwendbarer Medien
Frontend-Richtung & Blaupause – Wende Frontend Design und Design Taste an; lege Conversion-Flow, Tokens, responsives Verhalten, Assets und Akzeptanzprüfungen fest; generiere Web-Referenzen nur, wenn gerechtfertigt
Bau – Verwende den einfachsten Stack, der das Briefing erfüllt, und implementiere vollständigen Produktionscode
Browser-QA – Baue/Teste, inspiziere Screenshots bei Desktop/Tablet/Mobil, behebe Fehler und wiederhole
Bereitstellen & Live-Verifizieren – Stelle nur auf Anfrage bereit, inspiziere dann die echte URL und melde den verifizierten Alias

Phase 1: Kontext & Recherche

Bevor du Code schreibst, lies die nächstgelegenen Projekt-/Kundenanweisungen, das genehmigte Briefing, Meeting-Entscheidungen und Quelllinks. Verstehe dann die bestehende Marke des Kunden und sammle alle Assets, die du benötigst.

Markenextraktion

Rufe die Website des Kunden auf und extrahiere:

Farben: Inspiziere CSS-Custom-Properties, berechnete Stile auf Schlüsselelementen (Überschriften, Buttons, Hintergründe, Akzente). Notiere als Hex-Werte.
Schriftarten: Überprüfe Google Fonts-Links, font-family-Deklarationen und @font-face-Regeln. Nimm nichts an – viele Seiten verwenden Schriftarten, die wie gängige aussehen, aber keine sind.
Logo: Finde die Logo-Bild-URL (normalerweise im Header oder Footer). Hole die höchstmögliche Auflösung.
Designsprache: Notiere Abstandsmuster, Border-Radius-Verwendung, Schattenstile, Hintergrundbehandlungen von Abschnitten.

Assets-Sammlung

Dies ist entscheidend. Durchsuche die Bildverzeichnisse der Website, um einen vollständigen Katalog zu erstellen:

Rufe die Startseite und wichtige Seiten auf, extrahiere alle <img> src-Attribute und CSS background-image-URLs
Suche nach Mustern in den Bildpfaden (z.B. /wp-content/uploads/YYYY/MM/ für WordPress-Seiten)
Notiere für jedes Bild:
- Vollständige URL
- Beschreibender Name (was zeigt das Bild?)
- Abmessungen (aus dem Dateinamen oder durch Abrufen der Header)
- Kategorie (Foto, Illustration, Icon, Logo, Aufkleber)

Speichere diesen Katalog – du wirst während des gesamten Builds darauf verweisen.

Beispiel-Katalogeintrag:

URL: https://example.com/wp-content/uploads/2023/08/image-13-1024x768.jpeg
Beschreibung: Studenten, die zusammen im Klassenzimmer arbeiten
Abmessungen: 1024x768
Kategorie: foto
Verwendung für: Problem-Abschnitt, Galerie

Phase 2: Content-Extraktion

Wenn der Benutzer ein PDF, Word-Dokument oder ein anderes Inhaltsdokument bereitstellt:

Textinhalte

Extrahiere alle Überschriften, Fließtexte, Statistiken, Zitate und CTAs
Behalte die Abschnittsstruktur des Dokuments bei – sie bildet normalerweise die Seitenabschnitte ab
Notiere spezifische Formulierungen, die wörtlich beibehalten werden sollten (Taglines, bestätigte Behauptungen, Testimonial-Zitate)

Bildinhalte (NICHT ÜBERSPRINGEN)

Identifiziere jedes Bild im Dokument
Bestimme für jedes Bild, was es zeigt und zu welchem Abschnitt es gehört
Ordne Dokumentbilder tatsächlichen gehosteten URLs von der Website des Kunden zu (aus deinem Phase-1-Katalog)
Wenn ein Dokumentbild mit keiner katalogisierten URL übereinstimmt, notiere es als „benötigt Quelle“ und frage den Benutzer

Der Grund, warum dies wichtig ist: Marketingdokumente verwenden Bilder strategisch. Ein PDF, das Charakterillustrationen neben Inhalten über Gehirnwissenschaft zeigt, sagt dir, dass diese Illustrationen in den Gehirnwissenschaft-Abschnitt der Landing Page gehören. Sie zu ignorieren, erzeugt eine textlastige Seite, die den Punkt verfehlt.

Phase 3: Bildkatalog & Verifizierung

Bevor du etwas baust, verifiziere jede Bild-URL, die du verwenden willst.

Verifizierungsprozess

Für jede Bild-URL:

Rufe die URL auf und überprüfe den HTTP-Statuscode
Eine 200-Antwort mit korrektem Content-Type bedeutet, dass sie gut ist
Ein 404 oder anderer Fehler bedeutet, dass die URL falsch ist

Korrektur defekter URLs

Wenn eine Bild-URL 404 zurückgibt:

Gehe zurück zur Live-Seite und suche nach dem Bild anhand des partiellen Dateinamens
Rufe den Seitenquellcode ab, der ursprünglich das Bild enthielt
Suche nach dem korrekten Pfad – Dateinamen haben oft geringfügige Abweichungen (z.B. GYM_Kid-at-Desk-300x295.png vs GYM_Kid_AtDesk-222x300.png)
Rate niemals Dateinamen. Überprüfe immer gegen den tatsächlichen Server.

Endgültiger Katalog

Erstelle eine verifizierte Liste, die jeden Inhaltsabschnitt seinen Bildern zuordnet:

Hero: logo.png (verifiziert), character-teaching.png (verifiziert), sticker-owl.png (verifiziert)
Problem: classroom-photo.jpeg (verifiziert)
Brain Science: character-1.png (verifiziert), character-2.png (verifiziert), character-3.png (verifiziert), character-4.png (verifiziert)
Shift: school-kits.jpg (verifiziert), home-products.jpeg (verifiziert)
Gallery: classroom.jpeg, confidence.png, founders.jpeg (alle verifiziert)

Phase 4: Frontend-Richtung & Blaupause

Lade den erforderlichen Frontend-Skill-Stack und schließe das Design-Gate vor dem Code von oben ab. Entscheide, ob generierte Web-Referenzbilder nützlich sind. Lege den Conversion-Flow, die Abschnittsaufgaben, visuelle Tokens, Medienplan, Bewegungsabsicht, responsives Verhalten und Akzeptanzprüfungen vor der Implementierung fest.

Lehne die Richtung selbst ab, wenn sie unverändert für einen nicht verwandten Kunden wiederverwendet werden könnte. Eine kohärente künstlerische Richtung ist besser, als mehrere Skill-Ästhetiken zu mitteln.

Phase 5: Bau

Wähle den Implementierungs-Stack

Zwinge nicht jede Landing Page in eine Technologie. Wähle basierend auf dem tatsächlichen Projekt:

Bestehendes Repository oder Vorlage: Behalte dessen Framework, Laufzeit, Komponenten, Routing und Asset-Pipeline bei, es sei denn, eine Migration wird ausdrücklich angefordert.
Statische Kampagnenseite: Semantisches HTML, externes CSS und minimales JavaScript werden bevorzugt, wenn keine Komponentenarchitektur oder App-Verhalten benötigt wird.
Komponentengeführte oder interaktive Seite: React/Vite, Next.js oder der bestehende Stack des Repositorys sind gültig, wenn wiederverwendbare Komponenten, Integrationen, Zustand oder komplexe Bewegungen dies rechtfertigen.
Überprüfe Abhängigkeiten, bevor du sie importierst. Bevorzuge bestehende Projektbibliotheken gegenüber dem Hinzufügen modischer Pakete.

Die alte Standardeinstellung unten gilt nur für eine wirklich neue statische Seite.

Dateistruktur für statische Seiten

Halte es einfach – ein einzelnes Verzeichnis mit zwei Dateien:

projekt-name/
├── index.html
└── styles.css

Vermeide für eine einfache statische Seite unnötige Build-Tools und Framework-Abhängigkeiten. Dies ist ein Standard, kein Verbot, den tatsächlichen Stack des Projekts zu verwenden.

Design System Einrichtung (styles.css)

Beginne das Stylesheet mit dem extrahierten Markensystem:

:root {
  /* Markenfarben – von der Kundenseite extrahiert */
  --primary: #0f4661;
  --primary-dark: #0a3347;
  --accent: #f37b78;
  --accent-hover: #e06560;
  /* ... alle Markenfarben als Custom Properties */

  /* Neutrale Skala – immer definieren */
  --gray-50: #f8f9fa;
  --gray-100: #f0f2f5;
  --gray-200: #e2e5ea;
  --gray-300: #c8cdd5;
  --gray-400: #9ca3b0;
  --gray-500: #6b7280;
  --gray-600: #4b5563;
  --gray-700: #374151;
  --gray-800: #1f2937;
  --gray-900: #111827;

  /* Utility-Tokens */
  --shadow-sm: 0 1px 3px rgba(0,0,0,0.06);
  --shadow-md: 0 4px 20px rgba(0,0,0,0.08);
  --shadow-lg: 0 8px 40px rgba(0,0,0,0.12);
  --shadow-xl: 0 20px 60px rgba(0,0,0,0.16);
  --radius-sm: 0.375rem;
  --radius-md: 0.75rem;
  --radius-lg: 1rem;
  --radius-xl: 1.5rem;

  /* Übergänge */
  --transition: 0.3s cubic-bezier(0.4, 0, 0.2, 1);
  --transition-bounce: 0.4s cubic-bezier(0.34, 1.56, 0.64, 1);
}

body {
  font-family: 'ExtractedFont', -apple-system, BlinkMacSystemFont, sans-serif;
  color: var(--gray-700);
  background: var(--white, #ffffff);
  line-height: 1.6;
  -webkit-font-smoothing: antialiased;
}

Typografie-Regeln (KRITISCH)

Schlechte Typografie ist der #1 Grund, warum KI-Seiten amateurhaft aussehen. Befolge diese streng:

/* Mindestgrößen – niemals darunter gehen */
body { font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem); } /* 16-18px */
h1 { font-size: clamp(2.25rem, 1.5rem + 3vw, 4rem); }       /* 36-64px */

...

[truncated for translation]

Aston1690/claude-skill-landing-page

Was ist claude-skill-landing-page?

In Ihrer bevorzugten KI fragen

Dokumentation