--- name: create-explainer description: Make or revise a narrated explainer video from a topic, script, recording, or storyboard using Explainer Studio. Use for explainer video creation, voice-timed scenes, presenter animation, draft previews, and final render. --- # Create an explainer Use the bundled CLI at `python /scripts/explainer.py` (the plugin root is `../..` from this file). Keep the creative decisions and review in the chat. If no creator profile exists, run the [setup skill](../setup/SKILL.md) first. For creative planning and animation authoring, recommend Astra in Codex or Opus in Claude Code for best results. Sol and Sonnet are the respective minimum recommendations. The user selects the active model; do not silently switch models or block work based on this recommendation. Follow the [motion quality guide](references/motion-quality.md) for the approved presentation baseline and the native Engine composition route. ## Short-form video safe zones Keep all text and visual elements within the short-form video safe zone. For Facebook Reels, use a 9:16 canvas at 1080 × 1920. Follow the supplied Reels layout guide: reserve the top 250 px and bottom 250 px for interface overlays, leaving the central 1420 px as the working safe area. Treat this as a conservative layout template, not a guarantee that every device or placement uses identical UI bounds. Reels also place a vertical action rail on the right, with controls such as like, comment, and share. Keep the presenter’s face, captions, labels, and other essential content clear of that rail; do not assume the whole central band is unobstructed. Apply these bounds while planning every portrait scene, including motion paths and elements that enter during animation. If the user supplies a platform-specific guide, follow that guide. During preview review, compare the composition with the intended platform UI, adjust anything that could be covered, and reapprove the storyboard before final rendering. A prompt alone does not guarantee pixel-level compliance. ## Film workflow 1. Ask for the topic, target audience, desired length, and any facts or sources the user wants included. Infer reasonable defaults from the request. Research claims when facts could have changed. Write a short script in the saved language and speaking style, with one paragraph per scene. Show it in chat and wait for the user's approval before generating narration. 2. `init` a project under the saved output folder, then write the approved script to `script.txt`. Never overwrite an existing project or source media. If the user brings a recording, `attach-voice` it. If they selected ElevenLabs, run `synthesize` only after the script is approved and a configured voice ID and API key are available. The user's recording or selected TTS output is the film's timing source. 3. Run `transcribe` to create `words.json` with word timestamps; `import-words` supports a reviewed external word-timing file. Check that the transcript matches the script. Run `storyboard` to align paragraphs, then turn the result into a shot plan rather than accepting paragraph cards as the finished storyboard. For every scene, specify the idea being explained, the concrete visual that proves it, the visual cues and their narration word/time, the presenter pose, and how the composition changes. Use the bundled presenter and the approved motion quality guide as defaults unless the user chooses otherwise. Render narration captions by default as short, timed speech-bubble phrases beside the presenter, with a clear tail toward the avatar; keep the bubble away from the main visual and platform controls. Use the Engine's configurable `speechBubble` caption layout and adjust its placement and tail per format or scene as needed. Do not duplicate whole narration sentences as separate graphic copy. When the idea benefits from it, define a progressive visual build: one clear visual metaphor or model that adds, moves, or transforms elements as the narration advances, preserving the earlier elements so viewers can see how the idea develops. List its key visual states and tie each change to a narration beat. Use this as an optional technique, not a formula; for product explainers, prefer a faithful product walkthrough. `visual_cues` use project-owned image paths plus global `start`/`duration` seconds and optional normalized `x`, `y`, `width`, and `height` (0–1). Separate cues stage a sequence of visual reveals. Use one everyday analogy for an abstract concept. Keep on-screen copy short. Verify labels and numbers against sources. Show a frame-by-frame visual plan in chat and wait for an explicit yes before `approve`. For a graphic with multiple parts, keep its combined PNG as the cue asset and place transparent PNG crops plus a `manifest.json` with each crop’s filename and original `x`/`y` origin in a sibling `.layers/` folder. The renderer stages those parts with separate GSAP entrances in their original layout; avoid baking motion graphics into one flattened image. In portrait scenes, give the visual enough scale to read on a phone and keep it clear of the presenter and Reels controls. For object travel, drawn paths, transformations, or coordinated camera changes, author an original SVG/HTML composition with a paused GSAP timeline in the Engine project. The generic Studio cue exporter supplies preset entrances; use the [native composition route](references/motion-quality.md#native-engine-composition-route) to execute the richer storyboard. Retain the approved narration and avatar timings and keep the composition editable. 4. Run `render --preview`. Display the Engine-rendered preview and ask for specific revisions. Review the whole contact sheet and sample scene middles, not only opening/closing frames. Check that the supporting visual changes as the narration advances, each new element lands on its cue, progressive builds retain and transform earlier elements coherently, no scene holds a complete slide for most of its duration, and the presenter does not cover the subject. For layered graphics, review the actual rendered transitions as well as their combined still image. Editing the storyboard invalidates its approval hash until reviewed again. Once accepted, run `render` for the full file, then `check` and `contact-sheet`; inspect the contact sheet in chat. Use `sync-check` when faster-whisper is available to compare rendered speech with the source. Deliver the MP4 path and the editable Studio and Engine project folders in chat. Use `render-legacy` only to compare against the old Studio compositor. If a custom avatar is requested, follow the [avatar skill](../avatar/SKILL.md) before rendering. For a portrait cut, render `render --portrait --preview`, review its layout, then render `render --portrait`. For a new take, run `retime` into a new project and review the new storyboard. Only the user approves the script and storyboard. The agent may prepare files and run read-only checks while waiting. If a render fails, report the exact failed step; do not call the film complete. Engine-backed renders use Rhubarb phonetic cues when configured and map them to the bundled five mouth states; otherwise they use voice loudness. Obtain rights to user-supplied music, images, logos, and voice recordings before publication.