Explainer Video

/explainer-video

An explainer is a script with pictures attached, and this product can deliver it two genuinely different ways. Pick the deliverable before you make anything — the two paths cost different amounts, take different craft, and only one of them ends in a file the user can upload somewhere.

Route the deliverable first

1. A narrated sequence that becomes an mp4. Shots and stills cut on the timeline under a synthesized narration track, exported to a real video file. Choose this when the explainer has to leave the product: a YouTube upload, an ad, something embedded in a deck or a course. Generation is paid — the lengths, tiers and per-second price are in your system prompt, read them there and never quote a number from this file. Recipe: references/narrated-sequence.md.

2. A self-playing board. A single-file html artifact that draws its own lines and words on, in time, with captions — the "hand writing on a whiteboard" explainer, done with real type and real vectors instead of filmed footage. It plays in the artifact pane, the user can replay it and download the .html, it is free, it has no length ceiling, and every frame is exactly what you wrote. Choose this when the explainer lives in the conversation or on a page. Recipe: references/animated-board.md.

3. A project the user renders themselves. When they want broadcast-quality motion and are willing to run a build: remotion (React), motion-canvas (TypeScript), or manim for a mathematical explainer in the 3Blue1Brown idiom. Hand over and stop; do not half-build it here.

Ask which, in one line, when the request is ambiguous — "playing here, or a file you can upload?" is the whole question. If they have already said "for YouTube" or "post it on LinkedIn", they have answered it: path 1.

The one thing that does not exist

Nothing in this product encodes a rendered page into an mp4. The render sandbox holds ffmpeg and a font — no browser — so a board that plays in the pane stays in the pane. Say that in one plain sentence when it comes up, and offer the two honest ways round it: screen-record the artifact as it plays, or take path 3 and render a real file locally.

And never substitute one path for the other. Generating footage of a hand writing on a whiteboard and presenting it as the explainer is the specific failure to refuse: the writing will be illegible scribble, the words will be wrong, and the user pays per second for it. If they asked for a drawn board, build the board.

What the timeline actually gives you, and what it does not

Read this before promising a shot list, because the gap here changes the script:

• Stills do not move. There is no pan, no zoom, no Ken Burns, no keyframed transform. A still sits on screen at a fixed size for as long as you give it. The consequence is the load-bearing craft rule of path 1: motion comes from cutting, not from moving. To cover twelve seconds of narration you need three or four beats, not one still held for twelve seconds.
• Text is a fixed overlay — placed on a nine-point grid, sized, coloured, optionally boxed, up to 8 per clip and 200 characters each. It appears and disappears; it does not fly, type on, or count up. If the request needs lettering that animates, that is motion-graphics, or the board in path 2.
• Transitions are a fixed set and dissolves between beats are what an explainer wants; fadeblack between sections.
• Ceilings: 60 clips, 15 minutes, and the finished cut must be one canvas and one frame rate. Exact op names, parameters and enums: references/narrated-sequence.md.

Narration is the spine — write it first

The audio decides the picture, so the script is not a preliminary, it is the timing document. Two consequences that bite in practice:

• Voice the script BEFORE you plan shots. You cannot place narration on the timeline without knowing how long each segment runs, and you only learn that once the audio exists. Script → synthesize → measure → cut.
• A synthesized narration segment is named by its own opening words (the first 80 characters of what was spoken becomes the source's name). Two segments that open the same way are indistinguishable when you go to place them, and the edit is refused as ambiguous rather than guessing. So open every segment differently — which is good writing anyway.

Script craft for the ear — sentence length, numbers, acronyms, the pauses that punctuation buys — belongs to text-to-speech; that skill also owns how the audio gets synthesized. Do not re-derive it here. references/script-for-the-ear.md covers only what is specific to an explainer: beat structure, how much narration a single beat can carry, and where to put the one sentence the viewer will actually remember.

Workflow

1. Settle the deliverable (the three paths above) and the length. "Under 90 seconds" is a different film from "five minutes" — say which you are writing.
2. Write the script in beats. One idea per beat, one sentence of narration per beat where you can manage it, and a named visual for each. Show the user the beat list before you spend anything; a wrong structure is cheap to fix now and expensive after the shots exist.
3. Build it — references/narrated-sequence.md for path 1, references/animated-board.md for path 2.
4. Hand over the last step. Path 1 ends with the user pressing Export; editing is free and the export is on us, so say plainly that the file comes from that button. Path 2 is already playing.
5. Iterate on one thing at a time — the script, or a single beat's visual. Re-cutting the whole sequence to fix one line wastes the generations.

Guardrails

• Never fake the deliverable. No invented mp4 link, no "the video is attached", no placeholder for a board you did not write out in full.
• Never quote a price, a duration or an engine name from this file. Your system prompt is the only current source, and a stale quote is a lie about money.
• Get consent before spending on shots. The beat list is the checkpoint: agree the structure, then generate.
• No real people or public figures, no copyrighted characters, no copyrighted music. For a board, carry every visual with inline SVG and type — never invent an image URL or host.
• If a claim in the script is a fact about the user's own product or numbers, use their words; do not invent specifics to make a beat land.

Usage

/explainer-video $ARGUMENTS