SaaS-Landing-Skill

Was macht SaaS-Landing-Skill?

Erstelle eine einseitige SaaS-Landingpage. Agent, befolge diesen Workflow genau.

1. Kontext lesen

Bevor du etwas schreibst:

• Lies die DESIGN.md im aktuellen Arbeitsverzeichnis. Wenn sie fehlt, stoppe und fordere eine an.
• Identifiziere die Farbpalette, Typografie-Tokens und Layout-Prinzipien.
• Notiere den Abschnitt „Agent Prompt Guide“ – er überschreibt alle Anweisungen hier, falls ein Konflikt besteht.

2. Abschnitte planen

Erforderliche Abschnitte in dieser Reihenfolge:

1. Hero — Logo oder Wortmarke, Überschrift (Tagline-Eingabe), Unterüberschrift (1–2 Sätze), primärer CTA, sekundärer CTA. Verwende den Parameter hero_density als vertikalen Abstand in Pixeln.
2. Features — 3–6 Feature-Kacheln. Jede: Icon, kurzer Titel, 1–2 Sätze Beschreibung.
3. Sozialer Beweis — proof_count Logos oder Testimonials. Wenn 0, überspringe diesen Abschnitt.
4. Preise — 2–3 Stufen. Nur einfügen, wenn has_pricing wahr ist.
5. Footer CTA — großer, akzentfarbener Band mit einem Button zum Aufruf zum Handeln.
6. Footer — minimal: Links + Copyright.

3. Designsystem anwenden

• Alle Farben müssen aus den DESIGN.md-Tokens stammen. Erfinde keine Hex-Werte.
• Typografie: Verwende die deklarierte Display-Schriftart für Überschriften, die Textschriftart für alles andere.
• Layout: Beachte die Regeln für Raster, maximale Breite und Abschnittsabstände.
• Komponenten: Verwende deklarierte Button-/Karten-/Eingabemuster. Füge keine Schatten hinzu, wenn DESIGN.md unter „Tiefe & Höhe“ minimal angibt.
• Akzent: Verwende die Akzentfarbe nur einmal im Hero, einmal im Footer CTA und für alle Links. Überschwemme die Seite nicht damit.

4. Datei schreiben

Erstelle eine einzige eigenständige index.html mit:

• Gesamtes CSS inline in einem <style>-Block im <head>.
• System-Schriftarten als Fallback, falls die DESIGN.md-Schriftarten nicht von Google Fonts o. Ä. geladen werden können.
• Kein externes JS.
• Semantisches HTML (<header>, <main>, <section>, <footer>).
• Jedes bearbeitbare Element mit data-od-id="<eindeutiger-slug>" versehen, damit der Host- Kommentarmodus es ansteuern kann.

5. Selbstprüfung

Überprüfe vor dem Abschluss:

• Der gesamte Text ist inhaltlich sinnvoll, kein Lorem Ipsum (verwende die Eingaben für product_name und tagline; generiere plausible spezifische Copy für den Rest).
• Keine defekten Farbreferenzen (jeder CSS-Farbwert stammt aus der Palette der DESIGN.md oder ist eine gültige Alpha-/Fallback-Variante).
• Responsive Breakpoints entsprechen dem Abschnitt „Responsives Verhalten“ der DESIGN.md.
• Die Seite sieht bei 1440w, 768w und 375w gut aus (mental simulieren).
• Akzentfarbe insgesamt maximal zweimal verwendet.

6. Fertig

Schreibe nur index.html. Generiere keine separate CSS-Datei, JS-Datei oder README.

---

Für Skill-Autoren, die dies als Referenz lesen

Dies ist ein minimales, aber vollständiges Skill. Struktur:

saas-landing-skill/
├── SKILL.md    ← du bist hier
└── assets/
    └── base.html    (optionales Starter-Template; dieses Skill verwendet keins)

Dinge, die zu beachten sind:

• Der od: Front-Matter-Block ist optional für reine Claude-Code-Kompatibilität, aber das Hinzufügen aktiviert die typisierten Eingaben, Schieberegler, Vorschaumetadaten und Fähigkeitengates von OD.
• Der Workflow unterhalb des Front-Matters ist reines Markdown, das der Agent als sein System-Prompt liest.
• Die DESIGN.md wird als Mitarbeiter behandelt, nicht als Überschreibung. Das Skill gibt dem Agenten die Befugnis, zu überschreiben, wenn die Aufgabenstellung in Konflikt gerät, aber niemals neue Tokens zu erfinden.
• Die data-od-id-Markierung ist, wie wir Elemente mit dem Kommentarmodus verbinden. Skills, die Kommentarmodus-Kompatibilität wünschen, müssen ihre Ausgabe annotieren.

Siehe ../../skills-protocol.md für das vollständige Protokoll.