Product Launch Video

Create a launch film whose story, visual system, motion, and evidence all come from the product being launched. The deliverable is a rendered video plus the editable project that produced it.

Use HyperFrames when it is installed. A Remotion project is also supported; prefer maintained remocn components over recreating common animation primitives. Do not switch stacks after the storyboard is approved.

Inputs to lock

Before building, establish:

• product URL or source brief;
• audience and the one change in belief the film should create;
• aspect ratio, target duration, language, and narration choice;
• claims that may appear and the evidence behind each;
• whether an existing script must remain verbatim or may be restructured.

If any of these would materially change the film, ask once before starting.

Required output

Keep the project editable. At minimum, produce:

capture/                 product copy, screenshots, logos, and design tokens
STORYBOARD.md            approved shot-by-shot plan
SCRIPT.md                narration, when the film is narrated
design.md                type, color, spacing, motion, and framing rules
compositions/            source for every shot
renders/launch.mp4       final delivery

Do not treat a preview, storyboard, contact sheet, or silent draft as the final video.

Workflow

1. Capture the product

Inspect the supplied URL or assets. Preserve exact product copy, real UI, logos, typography, colors, and interface states. Record every usable asset and its source. Do not invent features, customers, metrics, or integrations.

If no website exists, create a small source record from the brief and supplied assets so later shots still have a traceable basis.

2. Choose the story

Write one sentence for each of these before storyboarding:

• the audience's present frustration;
• the product's distinctive mechanism;
• the proof the viewer should believe;
• the action the viewer should take.

Select only the beats the source material supports. A short film usually needs a hook, mechanism, proof, and close; it does not need a feature inventory.

Read references/story-and-shot-system.md when planning the sequence.

3. Establish the visual system

Derive design.md from the captured product rather than from a generic video template. Define the canvas, typography, color roles, grid, safe areas, visual density, motion character, caption treatment, and transition family.

Limit the film to one visual grammar. Repetition creates identity; a new style for every shot makes the film feel assembled from templates.

4. Storyboard before animation

For every shot, record:

• start and end time;
• narrative job;
• exact on-screen copy;
• source asset or UI state;
• composition and camera intent;
• entrance, development, and exit;
• transition to the next shot;
• any claim and its evidence source.

The frame must continue developing for its useful duration. Avoid an entrance animation followed by several seconds of static content.

Show the storyboard for approval before building the full film.

5. Build with maintained primitives

HyperFrames is preferred for HTML shot sequences. For Remotion, read references/remotion-and-remocn.md and use remocn for common typography, terminal, chart, background, and transition behaviors. Custom animation is appropriate only when the product requires a motion idea that the library cannot express.

Every shot must be deterministic at an arbitrary frame. Do not rely on runtime timers, non-seeded randomness, or interaction state that a renderer cannot reproduce.

6. Review the assembled film

Before rendering, inspect:

• first, middle, and final frames of every shot;
• every transition seam;
• text wrapping, clipping, contrast, and safe areas;
• timing against narration and music;
• product fidelity and claim accuracy;
• the full film at normal speed with audio;
• a silent pass, so the visual story still makes sense.

Run node scripts/check-project.mjs <project-dir> for the package-level project gate. Also run the native lint, validation, and render checks of the selected video stack.

Pause for approval on the assembled preview. Render the final MP4 only after approval.

Evidence boundary

A polished example demonstrates intended craft; it does not prove the skill improves model performance. Report separately:

• package and project checks;
• successful final render;
• human visual review;
• any comparative evaluation, only when recorded runs and scoring exist.

Never call the skill evaluated because one attractive video was produced.

Failure conditions

Stop rather than ship when:

• the primary product claim cannot be sourced;
• captured UI is replaced by invented interface chrome;
• a shot is illegible at delivery resolution;
• narration and picture disagree;
• the project cannot render deterministically;
• the editable source or final MP4 is missing.