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 the focal UI is on screen. Let the scene-level crossfade between beats carry the caption swap.
• Captions rise in from below. They start ~60px under their rest position with opacity 0 and slide up + fade in together (strong UI ease-out, e.g. Easing.bezier(0.16, 1, 0.3, 1)). Never have a caption appear in place or drop in from above — the upward motion is part of the visual identity.
• Captions live at the top, always at the same spot. Anchor every caption to a fixed top-of-frame position (e.g. ~100px from the top, horizontally centered) and reuse that position across every beat. Never put a caption below the focal UI, never let it drift from beat to beat. Reserve a consistent top "caption band" (~200–240px) and lay the focal slice out below it. Build a single TopCaption wrapper component and use it everywhere — don't position captions inline per scene.
• Captions are big. Default font size for a 1080-wide canvas is around 54px, weight 700, with a maxWidth so long lines wrap instead of running off-frame. They are headline-size callouts, not subtitle-size labels.
• Same caption across connected beats stays put. When two consecutive beats are conceptually parts of the same moment and share the exact same caption text (e.g. one beat shows tapping the day, the next shows the form opening — same headline applies to both), the caption must not re-animate at the cut. It rises and fades in once on the first beat, then on every continuation beat is rendered with staticEntry (or equivalent: instant full opacity, rest position, no slide). The two captions composite identically during the scene crossfade so the viewer perceives a single caption that persists across the cut, not a flicker. use this when the text is the same — if the caption changes at all between beats, let the new one rise-and-fade-in normally so the change reads.

When in doubt

Ask. A 10-second clarifying question saves a 2-minute render that misses the point.