Remotion video production
Turn source material into a coherent, editable video. Author the video in React; render from saved media. Follow the stages below, adapting to the user's instructions and existing project. Keep a brief production record so another agent can continue without reconstructing decisions.
1. Inspect the brief, assets, and capabilities
Identify the audience, intended takeaway, delivery format, tone, and available assets. Distinguish source facts, editorial interpretation, and unresolved information; do not invent missing factual steps, capabilities, or outcomes. Extract large inline assets before reading the document into context. Retain a source-to-scene mapping in the production project.
Inspect relevant images and recordings, not just filenames. Note framing, embedded labels, sound, and actions actually visible. Check whether this agent can inspect images, hear audio, run code, and provide a user-accessible preview. Missing perceptual capability requires the fallback in references/runtime.md; a script cannot determine those model capabilities or replace human judgment.
For an existing Node project, optionally run node <skill-dir>/scripts/doctor.mjs <project-dir>. It inventories dependencies; it does not prove render readiness. Use the project's package manager and lockfile. Follow the current Remotion best-practice skill when available, otherwise the official documentation.
2. Propose a direction and clarify only meaningful uncertainty
Give one recommended direction: audience/takeaway, rough duration and aspect ratio, scene progression, visual tone, and narration approach. Explain how the source and viewing purpose informed it. For structure and style choices, use references/editorial.md.
Ask a small number of focused questions when answers would change the factual content, audience, direction, or use of unavailable assets. Do not repeat questions already answered or require a questionnaire for every job. Continue independent work while waiting; unresolved essential facts must not be invented. If optional preferences remain unspecified, state reasonable assumptions and proceed within the user's authorization.
3. Write a compact storyboard
For each scene, record its purpose, source evidence, spoken words, on-screen emphasis, intended visual/motion, and approximate duration. Keep narration distinct from headings and captions. List unresolved facts separately. Treat the storyboard as an editorial document, not a new programming language. Test a representative sequence early if the visual or audio direction is uncertain.
4. Prepare media and measured timing
Give each media type an appropriate adapter. A speech request and a video-generation request need not share an input shape. Normalize their results to saved files and useful metadata, including duration, dimensions, generation settings, provenance, and required attribution where relevant.
Resolve media generation before previewing or rendering. Cache outputs by the input content and effective provider settings, and verify the cached files. Do not trigger paid or nondeterministic generation from React render functions or metadata evaluation.
For narration, keep display text separate from pronunciation text when needed. Measure actual audio duration, then allow enough time for the associated image and text to be understood. Use phrase or sentence timing when that is sufficient. Word highlighting requires reliable timestamps or alignment; evenly distributing characters is not accurate alignment.
For existing recordings, preserve or deliberately trim the original sound and derive captions from a transcript or transcription. Account for scene offsets, audio lead-in, pauses, and overlapping transitions. Use references/pipeline.md for adapter, timing, cache, and revision contracts. Bundled optional helpers extract inline images and validate caption ranges; usage and limitations are in references/runtime.md.
5. Implement in ordinary React/TypeScript
Reuse small components for recurring treatments and allow arbitrary React for subject-specific scenes. Data may hold text, media paths, timing, source references, and design tokens. Introduce a template schema only when repeated output of a known format justifies it. Do not create a general timeline interpreter, plugin registry, or orchestration service for a local video.
Drive motion from frame numbers; avoid wall-clock timers and uncontrolled randomness. Load required fonts and assets locally. Style can change typography, composition, motion, emphasis copy, pacing, and audio; changing a palette alone is not a complete style change. Reuse approved media and timing when only presentation changes.
Run focused type, asset, duration, and caption checks. Use bundled check-captions.mjs only for its documented timing contract. Tests belong around reusable timing/import/cache logic, not every cosmetic decision. Prefer existing components and small, verified changes when the agent has limited coding ability.
6. Preview before spending time on final export
Prefer Remotion Studio when the user can access it. Show the composition and explain what needs review: source fidelity, style, text/subject clipping, caption readability, motion, and sound. Inspect representative scenes, boundaries, and the ending yourself where supported. When the user requested review before export, provide the preview and wait for that review before final export. Existing approval or an explicit request to render can authorize proceeding; do not add an unconditional confirmation gate.
If interactive Studio is unavailable, produce representative stills and, when motion/audio needs review, a short low-resolution draft. A remote environment's localhost URL may be inaccessible to the user; deliver a reachable preview or local artifact. Stills do not establish motion or audio quality. Apply the human-review fallbacks in references/runtime.md and report exactly what was and was not reviewed.
7. Export, verify, and deliver
After any requested review is complete, use the project's installed Remotion CLI for routine export. See references/runtime.md for npx commands. Use the renderer API only when programmatic integration or batching merits it. Preserve user edits and regenerate only affected media when revising.
Check the exported file's dimensions, frame rate, duration, audio presence, first/last frames, caption changes, and scene boundaries. Play the full result when perceptual review is available; otherwise identify the remaining human review. A successful render or audio decode does not establish editorial quality, correct pronunciation, or a pleasant mix. Preview review and final-file verification are separate evidence.
Deliver the editable project, preview/export location, reproduction commands, and a concise status: implemented, preview checked, user reviewed, exported, final file checked. Only claim completed stages. Keep the production record with the production.
Keep reusable guidance independent of productions
Skills and distributable examples must be self-contained and subject-neutral. Keep private source text, images, audio, names, links, identifiers, file paths, and production-specific instructions in the production project. Do not include them in a reusable skill, its metadata, references, fixtures, or assets. Use newly invented examples if an example is necessary.
Document methods and decision criteria learned from a production without encoding its subject matter as a universal requirement. Verify the actual skill package contents before sharing or installing it.