Storytelling Landing Page
Use this skill to create immersive scroll-driven landing pages with a cinematic narrative arc, generated image assets, and a paste-ready developer build prompt. The reference bar is the Last Rites project: pinned zoom/pull-back, morphing flame-to-water soul object, draggable memory slider, particles, custom cursor, magnetic buttons, loading screen, transparent PNG overlays with mix-blend-mode: screen, and a two-tier CTA after a mandatory 2-second pinned pause.
Default output is planning plus build prompt. When the user asks you to actually build it, create the Vite project, generate or stub assets, use Open Design as a design/prototype sidecar when useful, run it locally, and verify by scrolling the working page end-to-end. A build is not complete until the page has been visually tested in a browser and judged for whether it feels cinematic/cool enough for the brand.
Routing With Open Design
Use the normal skill flow for narrative, scene planning, motion specs, prompts, and build prompts. Bring in Open Design when visual production is the bottleneck:
- If GPT Image 2 is unavailable, fails, times out, or produces weak/uncinematic images.
- If the user asks to make the site, prototype it, preview it, or "make things" rather than only write a prompt.
- If a fast visual direction is needed before hand-coding the final Vite/GSAP build.
Command:
/Users/yashovrattiwari/.openclaw/tools/openclaw-design make "<full storytelling landing page request, including intake answers, emotion, scroll type, soul object, element overlays, and asset constraints>"
Treat Open Design output as source material: reuse the strongest visual direction, layout, copy rhythm, and generated files, then preserve this skill's required GSAP/ScrollTrigger story mechanics and verification checklist. Do not stop because GPT Image 2 is not making images.
Phase 1 - Intake Interview
Ask these 5 questions one at a time. Do not batch them unless the user has already provided enough detail.
- Brand and purpose:
What is this website for - and who arrives at it? - Emotional register: offer grief/peace, hope/rebirth, wonder/awe, ambition/drive, calm/trust, urgency/excitement, or something else.
- Scroll type: A scroll reveal, B scroll plus drag chapters, C deep immersion, or D single scene zoom.
- Soul object: a simple centre-screen SVG that morphs in 2-3 stages, with named gradient stops that GSAP can tween.
- Element PNG overlays: 2-4 isolated physical elements on pure black, composited in code with
mix-blend-mode: screen.
Examples: flame to drop to ripple, seed to seedling to canopy, star to constellation to stardust, compass needle to true north, breath circle to wave to still water, spark to trail to light burst.
Phase 2 - Soul Object Spec
After intake, define the soul object with inline SVG, id="soulGrad", id="soul-stop-1/2/3", three scroll stages, glow colours, gradient colours, CSS morph values, mouse lerp offset, scroll sine drift, section opacity, and a GSAP breathing pulse.
Include GSAP stop-colour tween examples:
gsap.to('#soul-stop-1', { attr: { 'stop-color': '#...' }, duration: 1.4 });
Phase 3 - Scene Plan
Define 6-8 scenes based on the scroll type. Use:
# | ID | Name | Narrative beat | GSAP mechanic | Particle mode | Soul stage | BG image
Mandatory scene types:
- Hero: load animation, staggered text, subtle background zoom out on scroll
- Zoom: GSAP
pin:true+scrub:true, background scale1 -> 1.55 - Transition: background colour tween, particle mode switch
- Smooothy drag: only for Type B/C, horizontal memory/product/timeline cards
- Chapter/River: 4-layer parallax, text rises from
y:50 - Vastness: pull-back scale
1.38 -> 1.0, single centred serif line - CTA: 2-second pinned pause, then staggered entrance
The 2-second pinned pause before the CTA is mandatory. Never skip it.
Phase 4 - Interaction Layer
Always include custom lerp cursor, magnetic buttons, loading screen, right-side progress dots, top scroll progress bar, warm/cool/transition canvas particles, soul object breathing pulse, scroll morph, mouse parallax, two-tier CTA, secondary soft escape, and 4 trust chips.
Add for Type B: Smooothy-style draggable slider and animated SVG ring icons on cards.
Add for Type C: StringTune-style modules: StringProgress, StringParallax, StringSplit, StringCursor3, StringMagnetic.
Add for Type D: GSAP pin zoom only; no slider or StringTune modules.
Phase 5 - GPT Image 2 Prompts
Produce two image prompt sets.
Set A - Background JPGs
One 16:9 JPG prompt per scene.
- End every prompt with exactly:
No people. No text. No logos. Aspect ratio 16:9. Photorealistic. Cinematic colour grade. - Generation order: Hero, CTA, Zoom, Chapter, Vastness, Transition last.
- After image 1, prepend:
Same cinematic colour grade, photographic style, tonal range as the hero image - - Tell the user to upload previous generated images as references for visual continuity.
- For the transition image, upload both Hero and CTA as references and ask to blend both palettes.
- Filename pattern:
scene-01-hero.jpg,scene-02-zoom.jpg, etc.
Set B - Transparent PNG Elements
One square PNG prompt per element type chosen in intake.
- Pure black
#000000background everywhere outside the element is mandatory. - Element fills 50-70% of frame.
- Filename pattern:
element-[name].png. - End every prompt with exactly:
Pure black (#000000) everywhere else. Square format 1:1. Ultra high resolution. Photorealistic macro. - In the build prompt, every element image must use
.element-overlay { mix-blend-mode: screen; }.
Prompt formula:
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.
Image Generation Fallback
If GPT Image 2 is unavailable, fails, or produces weak assets:
- Try the configured image generation tool if available.
- If image generation is still blocked or the results are not good enough, use Open Design:
/Users/yashovrattiwari/.openclaw/tools/openclaw-design make "<full storytelling landing page request>" - If Open Design returns a useful project, inspect its generated files and port over the strongest direction into the Vite/GSAP build instead of blindly replacing this skill's motion system.
- If no images can be produced, build with cinematic CSS gradients, canvas particles, SVG overlays, and clearly named placeholder files so the site remains functional and asset prompts can be used later.
Do not stop only because image generation failed. Preserve the story, motion system, and final runnable page.
Phase 6 - Codex Build Prompt
Produce a complete paste-ready prompt for Codex, Cursor, or another coding agent. It must include project overview, tech stack, full file tree, complete package.json, complete vite.config.ts, complete index.html, complete src/styles.css, complete src/main.ts, complete src/soul.ts, src/particles.ts, src/cursor.ts, src/scroll.ts, src/loader.ts, and src/slider.ts only when B/C.
Required build details: Vite 5 + TypeScript, GSAP 3 + ScrollTrigger, inline soul SVG with soul-stop-1/2/3, data-particle sections, element PNG tags with class="element-overlay" and data-float-speed, nav, cursor, canvas, loader, progress dots, warm/cool palette variables, responsive breakpoint at 768px, image setup instructions for public/images/, fallback behavior if images are missing, and npm install plus npm run dev.
The build prompt must also include a mandatory final test section for the coding agent: run the app, open the local URL, scroll top-to-bottom at desktop and mobile widths, interact with the slider if present, verify pinned zoom/CTA pause/soul morph/particles/buttons/focus/no-overlap, capture hero/mid/CTA screenshots, and revise until the page feels visually strong rather than merely functional.
Required ScrollTrigger setup:
gsap.registerPlugin(ScrollTrigger);
ScrollTrigger.normalizeScroll(true);
ScrollTrigger.config({ fastScrollEnd: true });
window.addEventListener('load', () => ScrollTrigger.refresh());
Typography: distinctive serif plus clean sans. Never default to Inter, Roboto, Arial, or system-only typography for the final aesthetic.
Output Format
Always deliver in this order after intake is complete:
## Intake Summary
## Soul Object Spec
## Scene Plan
## Interaction Layer
## GPT Image 2 - Background Prompts (Set A)
## GPT Image 2 - Element PNG Prompts (Set B)
## Generation Order
## Codex Build Prompt
## Final Verification Plan
Quality Checklist
Before delivering a plan or build prompt, verify that intake is complete, the soul object has 3 stages and named gradient stops, the scene plan has 6-8 scenes, Type B/C includes the slider, Type C includes StringTune-style modules, CTA has the 2-second pinned pause, both image prompt sets are present, PNG overlays use mix-blend-mode: screen, all files are fully specified for a runnable Vite app, warm/cool palette variables exist, mobile rules start at 768px, filenames match everywhere, run instructions include npm install plus npm run dev, and the build prompt explicitly requires final browser scroll-through testing with screenshots and a visual quality pass.
Final Build Verification
When you actually build a page with this skill, do not call it done until you have tested it:
- Run install/build or dev server according to the project.
- Open the local page in a browser.
- Scroll from top to bottom on desktop and mobile widths, preferably using browser automation plus manual visual inspection when available.
- Confirm the hero loads, pinned zoom works, transition changes particle mode, slider works if present, soul object remains visible and morphs, CTA pause happens, buttons/focus states work, and text does not overlap.
- Capture screenshots at hero, mid-story, and CTA for both the main desktop viewport and at least one mobile viewport when practical.
- Make a judgment call: does it feel cinematic/cool enough for the requested brand? If not, tighten motion timing, contrast, spacing, image treatment, copy, or asset direction and retest the full scroll.
- Report the proof: local URL, viewport sizes, screenshots/observed states, fixes made after the first visual pass, and any remaining blockers.
Verification should be evidence-based. Do not deliver only a successful build log; the final answer must say what was observed while scrolling the working page.