/create-onboarding-video

name: create-onboarding-video
description: Produce short, punchy iOS app onboarding videos in Remotion that showcase a feature in action by animating isolated pieces of the UI (cropped components, not full screens) with nice UI-like transitions. Use when the user asks to create, build, or generate an onboarding video, app preview, feature demo clip, App Store preview, or any short video that demonstrates a mobile app feature using supplied screenshots.

Create Onboarding Video

Produce a **short, punchy iOS onboarding video** in Remotion that showcases one feature working. Output is meant to feel like an App Store preview zoomed into the moment that proves the feature works — not a tutorial, not a screen recording, not a marketing reel.

What you make

• **Length:** short. 3–8 seconds per onboarding screen, stitched together. Whole video rarely exceeds ~30s.
• **Style:** UI-first, **never the whole screen**. Each beat shows a **piece of the feature in action** — a single button being tapped, a toggle flipping, a row reordering, a sheet sliding up, a chart filling in — animated with **nice UI-like transitions** (springs, slides, scales, crossfades, masked reveals, shared-element swaps).
• **What "pieces" means:** crop, mask, or extract just the relevant component from the supplied still — the card, the input field, the tab bar, the empty state turning into a filled state. The rest of the UI is omitted, blurred, or implied by a tinted background. We are showcasing **what the feature *does*,** not what the whole app looks like.
• **Tone:** to the point. Each beat communicates one thing the feature does.
• **Output:** a Remotion project that renders to MP4 (and optionally a portrait variant for App Store previews).

Workflow

Follow this loop. **Do not skip the intake — guessing at flows produces generic videos.**

1. Intake — ask for stills + intent

For each onboarding screen the user wants to feature, collect:

1. **Still shots (screenshots)** of the screen — ask for **2–4 stills per screen** so you can show interaction states:

• resting state
• mid-interaction (button pressed, field focused, sheet halfway up, etc.)
• result state (data loaded, success, next screen)
• any variant worth showing (empty vs. filled, light vs. dark, etc.)

2. **What the feature is** — one or two sentences on what this screen does for the user and what makes it feel good. This drives which detail to zoom into. 3. **Order** — the sequence of screens in the onboarding flow. 4. **Optional:** brand color / accent, font if non-standard, target aspect ratio (default 1080×1920 portrait for iOS), end-card text/CTA.

Use `AskUserQuestion` when the user is vague. Don't start rendering until you have stills + intent for every screen.

2. Plan the shots

For each screen, identify the **single piece of the feature that proves the feature works** — the tapped button, the filling progress ring, the row that gets swiped, the field that auto-completes — and how it transitions to the next beat. **Never animate the whole screen.** Sketch the timeline (focal element → motion → result → next focal element) before writing components. Prefer:

• isolating/cropping/masking the relevant component out of the still and placing it on a tinted background
• showing the *interaction itself* (tap ripple, drag, focus, state change) rather than just the static layout
• shared-element transitions between beats (the button on beat 1 becomes the header on beat 2)
• subtle parallax / depth on layered elements
• spring-based motion over linear easing

3. Build with Remotion

**Always invoke the `remotion-best-practices` skill before writing Remotion code.** When you do, include this guidance in your prompt to it:

> Build a short iOS-app onboarding video. **Never render the whole screen** — each beat must show a *piece of the feature in action*: an isolated/cropped/masked UI component (button, card, row, sheet, field, chart, etc.) animating through the interaction that demonstrates what the feature does. Place it on a clean tinted background; the rest of the app chrome is omitted or implied. Use **nice UI-like transitions** — springs, masked reveals, shared-element morphs, crossfades, parallax — to move between beats. Prefer `spring()` over linear interpolation, use `<Sequence>` to chain beats, and keep each beat short (90–240 frames at 30fps). Stills go in `public/` and load via `staticFile()`; crop them with CSS `clip-path` / `overflow: hidden` / absolute positioning to extract the focal element.

Project conventions:

• Source stills in `public/<screen-name>/<state>.png`.
• One `<Composition>` per onboarding flow; one `<Sequence>` per screen-beat inside it.
• Components in `src/scenes/`, shared transitions in `src/transitions/`.
• Default 30fps, 1080×1920 portrait; expose width/height as props so the same scenes render landscape if asked.

4. Iterate

Render a preview, show it to the user, and ask which beats need to be slower, faster, or restaged. Treat the first render as a draft.

Operating rules

• **Stills are required.** If the user hasn't provided screenshots, stop and ask. Do not invent UI from descriptions.
• **Pieces of the UI, not the whole UI.** If you catch yourself rendering a full-screen mockup, stop and crop down to the component that carries the beat. The viewer should see the *feature in action*, not a tour of the app.
• **One feature per video.** If the user describes 5 unrelated features, propose splitting them into 5 videos.
• **Show, don't narrate.** No voiceover, no big text overlays explaining the feature — let the UI motion carry it. A short caption per beat is fine.
• **Captions are visible for the entire beat.** Each beat's supportive caption fades in within the first ~10–14 frames of the beat and remains on screen for the whole sequence. Do **not** delay caption entry to mid-beat or fade it out before the beat ends — the viewer should be able to read the line the entire time