peterfei/landing-page-skill

Landing Page Skill

Dieses Skill ist als agent-agnostisch konzipiert – Claude Code, Codex CLI, Cursor, Trae, OpenClaw, Hermes Agent oder jeder andere Agent, der markdown-basierte Skills unterstützt, kann es verwenden. Alle Dateiverweise erfolgen als relative Pfade relativ zum Stammverzeichnis dieses Skills.

Aktivierungsbedingungen

Das Skill wird aktiviert, wenn die Benutzereingabe eines der folgenden Auslösewörter enthält: landing page, Landing Page, Produktseite, Marketingseite, Homepage-Design, single page website, Zielseite.

Ehrlichkeitsgrenzen (Anwendbarkeitsprüfung)

Anwendbar:

1. Einseitige, konversionsorientierte Landing Pages (Lead-Generierung, Registrierung, Kaufabschluss)
2. Produkt-/Dienstleistungsseiten (SaaS, E-Commerce-Einzelprodukte, Beratungsdienstleistungen, Kurse)
3. Tech-Stack: Next.js 14/15 + Tailwind CSS (MVP-Phase)
4. Seiten mit klarem Konversionsziel (CTA)

Nicht anwendbar:

1. Mehrseitige Websites oder Blogs (über den Umfang einer einzelnen Seite hinaus)
2. Vollständige Anwendungen mit Backend-API, Datenbank oder Benutzerauthentifizierung
3. Komplexe Interaktionen (Echtzeit-Kollaboration, Datenvisualisierungs-Dashboards, Spiele)
4. Nicht-Web-Plattformen (Mini-Programme, native Apps, Desktop-Anwendungen)

Grenzerklärung: Dieses Skill generiert qualitativ hochwertigen Ausgangscode, der manuelle Anpassungen von Textdetails und Markenwerten erfordert. Es verspricht kein „One-Click-Perfection".

5-Phasen-Operationsprotokoll

Phase 1: Anforderungserfassung

Bestätige nacheinander die folgenden Informationen mit dem Benutzer (überspringen, falls bereits vom Benutzer bereitgestellt):

1. Produkt/Dienstleistung: Was ist es? Was ist das zentrale Wertversprechen?
2. Zielgruppe: Wer wird es nutzen? Welche Schmerzpunkte gibt es?
3. Konversionsziel: Was soll der Benutzer tun? (Registrieren/Kaufen/Herunterladen/Buchen)
4. Tech-Stack: Bestätige die Verwendung von Next.js 14/15 + Tailwind CSS
5. Markenstil-Präferenz: Wähle aus den 6 Stilen in references/aesthetic-styles.md
6. Wettbewerbsreferenzen: Gibt es bevorzugte Landing Pages zur Referenz? (optional)

Ausgabe: Anforderungszusammenfassungsdokument (Markdown-Liste), verwendet für Phase 2.

Phase 2: Strategieplanung

1. Branchenvorlage laden: Wähle basierend auf dem Produkttyp aus references/page-templates/ eine Vorlage:
   • SaaS-Produkt → references/page-templates/saas-product.md
   • E-Commerce-Einzelprodukt → references/page-templates/ecommerce.md
   • Andere → Allgemeine Struktur (Hero → Features → Benefits → Social Proof → CTA → Footer)
2. Ästhetikrichtung wählen: Wähle aus references/aesthetic-styles.md einen Stil und bestätige die Farbpalette
3. Textstruktur: Verwende references/copy-formulas/ zur Planung:
   • Hero-Headline: Formel „Ergebnis + Zielgruppe + Mechanismus" aus references/copy-formulas/hero-headlines.md
   • CTA-Text: Format „Verb + Nutzen" aus references/copy-formulas/cta-patterns.md
   • Einwandbehandlung: 5 Arten von Einwandvorlagen aus references/copy-formulas/objection-handling.md
4. Konversionsrahmen abbilden: Ordne den 7-teiligen Text den 11 DESIGNNAS-Elementen zu (siehe references/conversion-framework.md)

Ausgabe: Strategiedokument (mit Stilwahl, Farbrichtung, Textgliederung, Elementzuordnungstabelle).

Phase 3: Designsystem

Generiere Design-Token basierend auf references/design-system.md:

1. Typography Token: Display-Schriftart, Body-Schriftart, Headline-Schriftgrößenstaffelung
2. Color Token: Primary / Secondary / Accent / Neutral / Background / Text (hex + CSS-Variable)
3. Motion Token: PageLoad-Animation, Scroll-ausgelöste Animation, Hover-Interaktion (Typ + Dauer)
4. Layout Token: Grid-Typ, Abstandsstaffelung, Abschnittsbreite, asymmetrische Layoutregeln

Ausgabe: Design-Token-Dokument (direkt in tailwind.config.ts kopierbar).

Phase 4: Codegenerierung

Generiere Code gemäß references/tech-adapters/nextjs-tailwind.md:

1. Projektstruktur: app/page.tsx, app/layout.tsx, components/, lib/utils.ts, tailwind.config.ts
2. Komponentisierung: Jedes DESIGNNAS-Element als eigenständige Komponente (HeroSection, FeaturesSection usw.)
3. Tailwind-Konfiguration: Erweiterung der Designsystem-Token (colors, fonts, animations)
4. Responsivität: Verwende Breakpoints sm:/md:/lg:/xl:
5. Barrierefreiheit: Semantisches HTML, alt-Texte, Kontrast, focus-visible

Ausgabe: Vollständiger, ausführbarer Next.js-Projektcode.

Phase 5: Qualitätsvalidierung (Closed-Loop-Garantie)

5.1 Konversions-Check

• Abdeckung der 11 Elemente: Prüfen, ob Hero, Social Proof, Features, Benefits, How It Works, Testimonials, Pricing/CTA, FAQ, Scarcity, Footer enthalten sind (mindestens 7)
• CTA-Klarheit: Ist der CTA-Text im Format „Verb + Nutzen"?
• Hero-Headline: Folgt sie der Formel „Ergebnis + Zielgruppe + Mechanismus"?

5.2 Anti-Pattern-Erkennung (Einzelprüfung, siehe references/anti-patterns.md)

#	Regel	Erkennungslogik	Schweregrad
1	Übermäßige Schriftarten	Inter/Roboto/Arial als Display-Schriftart	Blockierend
2	Vorlagenfarben	Lila Verlauf + reiner weißer Hintergrund (Vorlagenkombination)	Blockierend
3	Unklarer CTA	CTA ist Submit/Learn More/Click Here	Blockierend
4	Fehlender Social Proof	Kein Social-Proof-Element unterhalb von Hero	Blockierend
5	Schwache Hero-Headline	Beginnt mit Welcome/Markenname, rein beschreibend	Blockierend
6	Fehlende mobile Optimierung	Keine sm:/md:/lg: Responsive-Breakpoints	Warnung
7	Barrierefreiheitsbasislinie	Fehlende alt/aria/semantische HTML-Attribute	Warnung
8	Fehlende SEO-Grundlagen	Keine meta/title/OG-Tags	Warnung
9	Leistungsrisiken	Große Bilder nicht optimiert, fehlendes Lazy Loading	Warnung
10	Token-Konsistenz	Hartcodierte Farben/nicht standardmäßige Abstände	Warnung

5.3 Automatischer Reparaturzyklus (Blockierende Regeln)

Wenn blockierende Regeln (1-5) nicht bestanden werden, wird automatisch ein Reparaturzyklus ausgeführt:

1. Generiere für jede nicht bestandene blockierende Regel spezifischen Reparaturcode
2. Ersetze nur den Code des Abschnitts, der die Regel ausgelöst hat (ändere keine anderen Abschnitte)
3. Führe die Erkennung der Regel erneut durch
4. Wiederhole die obigen Schritte, maximal 3 Runden
5. Wenn nach 3 Runden immer noch nicht bestanden → Melde den Fehlergrund und überlasse die Entscheidung dem Benutzer

5.4 Positive-Muster-Validierung (Empfehlend, siehe references/positive-patterns.md)

#	Muster	Erkennungslogik
P1	CTA „Verb+Nutzen"	CTA-Text entspricht Format „Verb + konkreter Nutzen"
P2	Hero „Ergebnis+Zielgruppe"	Headline enthält quantifizierbares Ergebnis + Zielgruppe
P3	Social-Proof-Element	Seite enthält ≥1 Social-Proof-Typ
P4	Dringlichkeit/Knappheit	Es gibt Dringlichkeitselemente (Plätze/Zeit/Preis)

Positive Muster lösen keine automatische Reparatur aus, sondern bieten Optimierungsvorschläge im Bericht.

Ausgabe: Prüfbericht (Anti-Pattern- + Positive-Muster-Markdown-Tabelle) + Zusammenfassung der automatischen Reparaturen (falls durchgeführt).

Phase 5.5: Iterative Optimierung (Optional)

Nach Abschluss von Phase 5 biete dem Benutzer 3 Optionen an:

A) Akzeptieren — Ausgabe des endgültigen vollständigen Projektcodes B) Spezifischen Abschnitt ändern — Der Benutzer gibt den zu ändernden Abschnitt und die Änderungsanforderungen an C) Spezifischen Abschnitt neu generieren — Der Benutzer gibt den Abschnitt an, der von Grund auf neu generiert werden soll

Iterationsregeln:

• Änderungen/Neugenerierungen betreffen nur den vom Benutzer angegebenen Abschnitt (Abschnittsebene)
• Nach jeder Änderung: Führe erneut die Anti-Pattern-Erkennung für die Regeln durch, die diesen Abschnitt betreffen
• Maximal 3 Iterationsrunden, danach Ausgabe der aktuellen Version
• Jede Runde gibt ein Änderungsprotokoll aus: „Runde N: Geänderte [Abschnitte], Erneut geprüft [Regeln]"

Index

Tech-Stack-Adapter

• Next.js 14/15 + Tailwind CSS → references/tech-adapters/nextjs-tailwind.md

Branchenvorlagen

• SaaS-Produktseite → references/page-templates/saas-product.md
• E-Commerce-Produktseite → references/page-templates/ecommerce.md

Textformelbibliothek

• Hero-Headline → references/copy-formulas/hero-headlines.md
• CTA-Muster → references/copy-formulas/cta-patterns.md
• Einwandbehandlung → references/copy-formulas/objection-handling.md

Designreferenzen

• Konversionsrahmen → references/conversion-framework.md
• Designsystem → references/design-system.md
• Ästhetikstile → references/aesthetic-styles.md
• Anti-Pattern-Erkennung → references/anti-patterns.md
• Positive-Muster-Erkennung → references/positive-patterns.md

Hinweise zur Agentenübergreifenden Umgebungsanpassung

Dieses Skill ist als agent-agnostisch konzipiert und mit den folgenden Laufzeiten kompatibel:

Laufzeit	Unterstützungsweise	Bemerkungen
Claude Code	Nativ unterstützt	Empfohlen, Aktivierung über /agent oder Auslösewörter
Codex CLI	Kompatibel	Direktes Laden von SKILL.md
Cursor	Kompatibel	Kopieren in .cursorrules oder Verwendung mit Composer
Trae	Kompatibel	Direktes Laden von SKILL.md
OpenClaw	Kompatibel	Befolgt das skills.sh-Protokoll
Hermes Agent	Kompatibel	Direktes Laden von SKILL.md
Andere markdown-basierte Skill-Laufzeiten	Kompatibel	Jede Laufzeit, die YAML-Frontmatter + Markdown unterstützt

Pfadkonvention

Alle Dateiverweise erfolgen als relative Pfade relativ zum Stammverzeichnis dieses Skills:

• references/xxx.md
• assets/xxx.svg
• scripts/xxx.py

Der Agent oder Benutzer löst sie basierend auf dem eigenen Installationsort auf, ohne Abhängigkeit von absoluten Pfaden.

Selbstständigkeitsprinzip

SKILL.md enthält alle notwendigen Informationen und kann direkt kopiert und verwendet werden. Die Dateien in references/ sind tiefgehendes Ergänzungswissen und können bei Bedarf geladen werden.

Dieses Skill folgt dem offenen Agent Skills-Protokoll.