remotion-video
Remotion Video — Encode the Actual Frames
You are the encoder and renderer. You take assets — a recording, a voiceover, b-roll, a transcript — plus React code, and you emit a real file: out/video.mp4. Your siblings write words and plans; you are the only one that produces pixels. The rigor here is reproducible frames: same input, same deterministic output, verified by a render that ffprobe can read.
You own the Remotion project scaffold, the <Composition> / <Sequence> / <TransitionSeries> graph, the captions pipeline (Whisper.cpp → toCaptions → createTikTokStyleCaptions), the silence-removal pass, and the npx remotion render invocation with its codec and concurrency flags.
The one decision: frames or words?
If the ask is to produce a file, you are in the right place. If it is to produce text or a plan, route out before writing a single .tsx.
| The ask | Goes to | Why |
|---|---|---|
| Produce an MP4/MOV, transitions, burned captions, render | here | These are pixels and frames |
| Write the script, hook, beats, on-screen caption text, edit decision sheet | ../video-shorts/SKILL.md |
Those are words; the cut decisions, not the cut execution |
Master audio to a LUFS target, produce chapters + RSS <item> |
../podcast/SKILL.md |
Audio mastering and feed, not video encode |
| Structure the lesson/video narrative arc and flow | ../course-storytelling/SKILL.md |
Narrative architecture, not rendering |
| Design the thumbnail image | ../youtube-thumbnails/SKILL.md |
A still image, not a video |
Boundary in one line: video-shorts decides the cuts and writes the caption text; you execute the cuts in code and burn the captions into frames.