skeletorflet/opencode-supreme-setup

SaaS-Landingpage Skill

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

1. Kontext lesen

Bevor du irgendetwas schreibst:

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

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 hero_density Parameter als vertikalen Abstand in px.
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 Balken mit einem Button als Handlungsaufforderung.
6. Footer — minimal: Links + Copyright.

3. Design-System 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 Körper-Schriftart für alles andere.
• Layout: Respektiere das Raster, die maximale Breite und die Abschnittsabstandsregeln.
• Komponenten: Verwende die deklarierten Button-/Karten-/Eingabemuster. Füge keine Schatten hinzu, wenn DESIGN.md unter „Tiefe & Höhe“ „minimal“ angibt.
• Akzentfarbe: 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 einzelne in sich geschlossene 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 editierbare Element mit data-od-id="<einzigartiger-slug>" versehen, damit der Kommentarmodus der Host-App es anvisieren kann.

5. Selbstprüfung

Bevor du fertig bist, überprüfe:

• Der gesamte Text ist inhaltlich sinnvoll, kein Lorem Ipsum (verwende die product_name und tagline Eingaben; generiere plausible, spezifische Kopien für den Rest).
• Keine kaputten Farbverweise (jeder CSS-Farbwert stammt aus der DESIGN.md-Palette oder einer gültigen 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. Erstelle keine separate CSS-Datei, JS-Datei oder README.

---

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

Dies ist ein minimaler, aber vollständiger Skill. Struktur:

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

Wissenswertes:

• Der od: Frontmatter-Block ist optional für die reine Claude-Code-Kompatibilität, aber wenn er hinzugefügt wird, aktiviert er OD's typisierte Eingaben, Schieberegler, Vorschaumetadaten und Capability-Gating.
• Der Workflow unter dem Frontmatter ist reines Markdown, das der Agent als sein System-Prompt liest.
• DESIGN.md wird als Kollaborateur behandelt, nicht als Überschreibung. Der Skill gibt dem Agenten die Autorität, bei Konflikten zu überschreiben, aber niemals, neue Tokens zu erfinden.
• data-od-id-Tagging ist die Methode, um Elemente mit dem Kommentarmodus zu verbinden. Skills, die Kommentarmodus-Kompatibilität wünschen, müssen ihre Ausgabe entsprechend annotieren.

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