Storytelling Landing Page

Was macht Storytelling Landing Page?

Nutze diese Fähigkeit, um immersive, scroll-getriebene Landing Pages mit einem cineastischen Erzählbogen, generierten Bild-Assets und einem paste-ready Build-Prompt für Entwickler zu erstellen. Das Referenzprojekt ist „Last Rites“: Pinning-Zoom/Rückwärtszoom, morphierendes Soul-Object (Flamme zu Wasser), ziehbarer Erinnerungs-Slider, Partikel, benutzerdefinierter Cursor, magnetische Buttons, Ladebildschirm, transparente PNG-Overlays mit mix-blend-mode: screen und ein zweistufiger Call-to-Action (CTA) nach einer obligatorischen 2-Sekunden-Pausierung.

Standardmäßig wird eine Planung plus Build-Prompt ausgegeben. Wenn der Benutzer tatsächlich bauen möchte, erstelle das Vite-Projekt, generiere oder illustriere Assets, verwende bei Bedarf Open Design als Design-/Prototyping-Seitenwagen, führe es lokal aus und überprüfe das funktionierende Scrollen der Seite von Anfang bis Ende. Ein Build ist erst abgeschlossen, wenn die Seite visuell in einem Browser getestet wurde und beurteilt wurde, ob sie sich cineastisch/cool genug für die Marke anfühlt.

Routing mit Open Design

Verwende den normalen Ablauf der Fähigkeit für Erzählung, Szenenplanung, Bewegungs-Spezifikationen, Prompts und Build-Prompts. Ziehe Open Design hinzu, wenn die visuelle Produktion zum Engpass wird:

• Wenn GPT Image 2 nicht verfügbar ist, fehlschlägt, eine Zeitüberschreitung hat oder schwache/uncineastische Bilder erzeugt.
• Wenn der Benutzer bittet, die Seite zu erstellen, einen Prototypen zu bauen, eine Vorschau zu machen oder „Dinge zu machen“, anstatt nur einen Prompt zu schreiben.
• Wenn eine schnelle visuelle Richtung benötigt wird, bevor der finale Vite/GSAP-Build von Hand codiert wird.

Befehl:

/Users/yashovrattiwari/.openclaw/tools/openclaw-design make "<vollständige Anfrage zur Storytelling-Landingpage, einschließlich Intake-Antworten, Emotion, Scroll-Typ, Soul-Object, Element-Overlays und Asset-Beschränkungen>"

Behandle die Open Design-Ausgabe als Quellmaterial: Verwende die stärkste visuelle Richtung, das Layout, den Copy-Rhythmus und die generierten Dateien wieder, bewahre aber die erforderlichen GSAP/ScrollTrigger-Story-Mechaniken und die Checkliste zur Verifikation dieser Fähigkeit. Hör nicht auf, nur weil GPT Image 2 keine Bilder erstellt.

Phase 1 – Intake-Interview

Stelle diese 5 Fragen nacheinander. Fasse sie nicht zusammen, es sei denn, der Benutzer hat bereits genug Details geliefert.

1. Marke und Zweck: „Wofür ist diese Website – und wer besucht sie?“
2. Emotionaler Register: Biete Trauer/Frieden, Hoffnung/Wiedergeburt, Staunen/Ehrfurcht, Ehrgeiz/Antrieb, Ruhe/Vertrauen, Dringlichkeit/Aufregung oder etwas anderes an.
3. Scroll-Typ: A Scroll Reveal, B Scroll plus Drag-Kapitel, C Tiefenimmersion oder D Einzelszene Zoom.
4. Soul-Object: Ein einfaches, mittig platziertes SVG, das sich in 2-3 Stufen morphisch verändert, mit benannten Gradient-Stopps, die GSAP interpolieren kann.
5. Element-PNG-Overlays: 2-4 isolierte physische Elemente auf reinem Schwarz, im Code mit mix-blend-mode: screen zusammengesetzt.

Beispiele: Flamme zu Tropfen zu Welle, Samen zu Keimling zu Krone, Stern zu Konstellation zu Sternenstaub, Kompassnadel zu Norden, Atemkreis zu Welle zu stillem Wasser, Funke zu Lichtspur zu Lichtblitz.

Phase 2 – Soul-Object-Spezifikation

Nach dem Intake definiere das Soul-Object mit Inline-SVG, id="soulGrad", id="soul-stop-1/2/3", drei Scroll-Stufen, Glühfarben, Gradient-Farben, CSS-Morph-Werten, Maus-Lerp-Versatz, Scroll-Sinus-Drifts, Abschnitts-Deckkraft und einem GSAP-Atem-Puls.

Füge GSAP-Stopp-Farb-Interpolationsbeispiele ein:

gsap.to('#soul-stop-1', { attr: { 'stop-color': '#...' }, duration: 1.4 });

Phase 3 – Szenenplan

Definiere 6-8 Szenen basierend auf dem Scroll-Typ. Verwende:

# | ID | Name | Erzählbeat | GSAP-Mechanik | Partikel-Modus | Soul-Stufe | Hintergrundbild

Obligatorische Szenentypen:

• Hero: Ladeanimation, gestaffelter Text, subtiler Hintergrund-Zoom beim Scrollen
• Zoom: GSAP pin:true + scrub:true, Hintergrundskalierung 1 -> 1.55
• Übergang: Hintergrundfarben-Interpolation, Partikelmoduswechsel
• Smooothy Drag: nur für Typ B/C, horizontale Erinnerungs-/Produkt-/Zeitleistenkarten
• Kapitel/Fluss: 4-schichtige Parallaxe, Text steigt aus y:50 auf
• Weite: Rückwärtszoom-Skalierung 1.38 -> 1.0, einzelne zentrierte Serifenlinie
• CTA: 2-Sekunden-Pinning-Pause, dann gestaffelter Eintritt

Die 2-Sekunden-Pinning-Pause vor dem CTA ist obligatorisch. Überspringe sie niemals.

Phase 4 – Interaktionsschicht

Füge immer hinzu: benutzerdefinierten Lerp-Cursor, magnetische Buttons, Ladebildschirm, rechte Fortschrittspunkte, obere Scroll-Fortschrittsleiste, warme/kalte/Übergangs-Canvas-Partikel, atmenden Puls des Soul-Objects, Scroll-Morph, Maus-Parallaxe, zweistufigen CTA, sekundären weichen Escape und 4 Vertrauens-Chips.

Für Typ B: Smooothy-ziehbaren Slider und animierte SVG-Ring-Icons auf Karten. Für Typ C: StringTune-artige Module: StringProgress, StringParallax, StringSplit, StringCursor3, StringMagnetic. Für Typ D: Nur GSAP-Pin-Zoom; kein Slider oder StringTune-Module.

Phase 5 – GPT Image 2 Prompts

Erstelle zwei Sets von Bild-Prompts.

Set A – Hintergrund-JPGs

Ein 16:9 JPG-Prompt pro Szene.

• Beende jeden Prompt mit genau: No people. No text. No logos. Aspect ratio 16:9. Photorealistic. Cinematic colour grade.
• Generierungsreihenfolge: Hero, CTA, Zoom, Kapitel, Weite, Übergang zuletzt.
• Nach Bild 1 füge voran: Same cinematic colour grade, photographic style, tonal range as the hero image -
• Sage dem Benutzer, er soll zuvor generierte Bilder als Referenz für visuelle Kontinuität hochladen.
• Für das Übergangsbild lade sowohl Hero als auch CTA als Referenz hoch und bitte, beide Paletten zu mischen.
• Dateinamensmuster: scene-01-hero.jpg, scene-02-zoom.jpg, usw.

Set B – Transparente PNG-Elemente

Ein quadratischer PNG-Prompt pro im Intake gewähltem Elementtyp.

• Reines Schwarz #000000 als Hintergrund überall außerhalb des Elements ist obligatorisch.
• Element füllt 50-70 % des Rahmens aus.
• Dateinamensmuster: element-[name].png.
• Beende jeden Prompt mit genau: Pure black (#000000) everywhere else. Square format 1:1. Ultra high resolution. Photorealistic macro.
• Im Build-Prompt muss jedes Elementbild .element-overlay { mix-blend-mode: screen; } verwenden.

Prompt-Formel:

Single isolated [ELEMENT] on pure black background. [Texture, light, detail description]. [Scale - fills X% of frame]. No background scenery, no context, no shadow extending far beyond the object. Pure black (#000000) everywhere else. Square format 1:1. Ultra high resolution. Photorealistic macro.

Fallback der Bilderzeugung

Wenn GPT Image 2 nicht verfügbar ist, fehlschlägt oder schwache Assets produziert:

1. Versuche das konfigurierte Tool zur Bilderzeugung, falls verfügbar.
2. Wenn die Bilderzeugung immer noch blockiert ist oder die Ergebnisse nicht gut genug sind, verwende Open Design: /Users/yashovrattiwari/.openclaw/tools/openclaw-design make "<vollständige Anfrage zur Storytelling-Landingpage>"
3. Wenn Open Design ein nützliches Projekt zurückgibt, überprüfe seine generierten Dateien und portiere die stärkste Richtung in den Vite/GSAP-Build, anstatt das Bewegungssystem dieser Fähigkeit blind zu ersetzen.
4. Wenn keine Bilder produziert werden können, baue mit cineastischen CSS-Gradienten, Canvas-Partikeln, SVG-Overlays und klar benannten Platzhalterdateien, damit die Seite funktionsfähig bleibt und Asset-Prompts später verwendet werden können.

Hör nicht auf, nur weil die Bilderzeugung fehlgeschlagen ist. Bewahre die Geschichte, das Bewegungssystem und die endgültig ausführbare Seite.

Phase 6 – Codex Build-Prompt

Erstelle einen vollständigen, paste-ready Prompt für Codex, Cursor oder einen anderen Codierungs-Agenten. Er muss enthalten: Projektübersicht, Tech-Stack, vollständigen Dateibaum, vollständige package.json, vollständige vite.config.ts, vollständige index.html, vollständige src/styles.css, vollständige src/main.ts, vollständige src/soul.ts, src/particles.ts, src/cursor.ts, src/scroll.ts, src/loader.ts und src/slider.ts nur wenn B/C.

Erforderliche Build-Details: Vite 5 + TypeScript, GSAP 3 + ScrollTrigger, Inline-Soul-SVG mit soul-stop-1/2/3, data-particle-Abschnitte, Element-PNG-Tags mit class="element-overlay" und data-float-speed, Nav, Cursor, Canvas, Loader, Fortschrittspunkte, warme/kalte Palette-Variablen, responsiver Breakpoint bei 768px, Bild-Setup-Anweisungen für public/images/, Fallback-Verhalten bei fehlenden Bildern und npm install plus npm run dev.

Der Build-Prompt muss auch einen obligatorischen finalen Testabschnitt für den Codierungs-Agenten enthalten: Führe die App aus, öffne die lokale URL, scrolle auf dem Desktop und in mobilen Breiten von oben nach unten, interagiere mit dem Slider falls vorhanden, überprüfe Pinning-Zoom/CTA-Pause/Soul-Morph/Partikel/Buttons/Fokus/keine Überlappung, mache Screenshots von Hero/Mitte/CTA und überarbeite, bis sich die Seite visuell stark anfühlt, nicht nur funktional.

Erforderliche ScrollTrigger-Konfiguration:

gsap.registerPlugin(ScrollTrigger);
ScrollTrigger.normalizeScroll(true);
ScrollTrigger.config({ fastScrollEnd: true });
window.addEventListener('load', () => ScrollTrigger.refresh());

Typografie: markante Serife plus saubere Sans. Verwende niemals nur Inter, Roboto, Arial oder System-Schriftarten für die endgültige Ästhetik.

Ausgabeformat

Liefere immer in dieser Reihenfolge, nachdem das Intake abgeschlossen ist:

## Intake-Zusammenfassung
## Soul-Object-Spezifikation
## Szenenplan
## Interaktionsschicht
## GPT Image 2 – Hintergrund-Prompts (Set A)
## GPT Image 2 – Element-PNG-Prompts (Set B)
## Generierungsreihenfolge
## Codex Build-Prompt
## Abschließender Prüfplan

Qualitäts-Checkliste

Bevor du einen Plan oder Build-Prompt lieferst, überprüfe: Intake ist vollständig, das Soul-Object hat 3 Stufen und benannte Gradient-Stopps, der Szenenplan hat 6-8 Szenen, Typ B/C enthält den Slider, Typ C enthält StringTune-artige Module, CTA hat die 2-Sekunden-Pinning-Pause, beide Bild-Prompt-Sets sind vorhanden, PNG-Overlays verwenden mix-blend-mode: screen, alle Dateien sind vollständig für eine lauffähige Vite-App spezifiziert, warme/kalte Palette-Variablen existieren, mobile Regeln beginnen bei 768px, Dateinamen stimmen überall überein, Ausführungsanweisungen enthalten npm install plus npm run dev und der Build-Prompt fordert ausdrücklich abschließende Browser-Scroll-Durchgangstests mit Screenshots und einer visuellen Qualitätskontrolle.

Abschließende Build-Überprüfung

Wenn du tatsächlich eine Seite mit dieser Fähigkeit baust, erkläre sie nicht für fertig, bevor du sie getestet hast:

1. Führe die Installation/den Build oder den Dev-Server gemäß dem Projekt aus.
2. Öffne die lokale Seite in einem Browser.
3. Scrolle auf dem Desktop und in mobilen Breiten von oben nach unten, vorzugsweise mit Browser-Automatisierung plus manueller visueller Inspektion, wenn verfügbar.
4. Bestätige: Hero wird geladen, Pinning-Zoom funktioniert, Übergang ändert den Partikelmodus, Slider funktioniert falls vorhanden, Soul-Object bleibt sichtbar und morphischt, CTA-Pause tritt ein, Buttons/Fokus-Zustände funktionieren und Text überlappt nicht.
5. Mache Screenshots bei Hero, Mitte und CTA sowohl für den Haupt-Desktop-Viewport als auch für mindestens einen mobilen Viewport, wenn praktikabel.
6. Triff ein Urteil: Fühlt es sich cineastisch/cool genug für die angeforderte Marke an? Falls nicht, verschärfe Bewegungs-Timing, Kontrast, Abstände, Bildbehandlung, Copy oder Asset-Richtung und teste das gesamte Scrollen erneut.
7. Berichte den Nachweis: lokale URL, Viewport-Größen, Screenshots/beobachtete Zustände, nach dem ersten visuellen Durchlauf vorgenommene Korrekturen und verbleibende Blockaden.

Die Überprüfung sollte evidenzbasiert sein. Liefere nicht nur ein erfolgreiches Build-Log; die endgültige Antwort muss sagen, was beim Scrollen der funktionierenden Seite beobachtet wurde.