# Promo Video Maker > Plan and produce software or product promotional videos from copywriting through real UI recording, TTS narration, subtitles, timeline editing, FFmpeg composition, and media validation. Use when creating or remaking a demo or promo video, including official brand and casual developer-led styles. Do not use for simple playback, transcoding-only requests, or image-only design. - Skill: `vatebur/promo-video-maker` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add vatebur/promo-video-maker` - Raw SKILL.md: https://api.skillmd.com/api/skills/vatebur/promo-video-maker/raw - Safety review: pending (external: skill-scanner PASS, skillspector CAUTION) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: vatebur (https://skillmd.com/u/vatebur) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/vatebur/promo-video-maker --- # Promo Video Maker Produce a truthful, publishable video package: script, raw footage, narration, subtitles, audio/video timeline, rendered deliverables, and verification evidence. ## Route the work - For copywriting, titles, descriptions, or choosing between **official** and **casual developer-led** tone, read [references/writing-styles.md](references/writing-styles.md). - When a live web UI must be demonstrated, read [references/recording.md](references/recording.md). Use an available browser-testing skill if one exists in the environment. - When generating narration or aligning speech, read [references/audio.md](references/audio.md). - When editing, adding subtitles, choosing resolution, or exporting, read [references/rendering.md](references/rendering.md). Read only the references needed for the requested deliverables. A complete end-to-end video requires all four. ## Core workflow 1. Inspect the project and identify only demonstrable facts: audience, problem, main actions, limits, and safety notes. 2. Choose a tone from the writing guide. Write the narration, on-screen phrases, shot list, title, and description before recording. 3. Record the actual product where possible. Reconcile the script with real UI states; do not fabricate disabled or unavailable actions. 4. Resolve the TTS provider and model, retrieve its current voice catalog, and show the relevant voices to the user. Require an explicit voice choice before synthesis unless the user already supplied an exact, currently valid voice. Then generate narration, measure its actual duration and sentence boundaries, and treat the finished audio as the master clock. 5. Map every spoken idea to a relevant shot. Create editable timeline and subtitle sources before rendering. 6. Render the requested aspect ratios and resolutions. Preserve raw media and reproducible scripts separately from exports. 7. Validate every final file with metadata inspection, full decode, visual frame sampling, audio-level checks, and state-restoration evidence when live services were changed. ## Non-negotiable invariants - Never place passwords, API keys, cookies, or tokens in scripts, docs, commands committed to the project, media metadata, or screenshots. Accept secrets at runtime via environment variables or no-echo prompts. - External TTS calls, paid APIs, live service actions, and other state changes still require the user's choice or authorization. A video request does not grant unrelated access. - Before TTS generation, list the currently available voices from an official provider source and let the user choose. Do not silently select a voice or make paid audition clips; verify and reuse an exact voice only when the user has already chosen it. - Before operating a live service, record its initial state. Restore that state after recording and verify it in a fresh session. Do not stop a service that was already running unless the user explicitly permits it. - Do not claim unsupported capabilities, built-in public exposure, universal compatibility, or security guarantees. Show the real product and state limitations in the description when relevant. - Never disable TLS verification to make an API work. Repair the CA path or use the maintained system CA bundle. - Do not label interpolated video as natively recorded at a higher frame rate. Report actual capture and export frame rates. - Default to 1920×1080, 16:9 for a general desktop deliverable only when the user does not specify a format. Do not silently crop important UI to force an aspect ratio. ## Deliverable layout Use the project's existing convention when present. Otherwise prefer: ```text video/ ├── copy/ # narration, shot list, titles, descriptions ├── raw/ # untouched screen recordings and source audio ├── audio/ # processed narration and reproducible generators ├── project/ # timeline, subtitles, render and recording scripts └── exports/ # final publishable media ``` Large binary files may need Git LFS or external artifact storage; do not assume they belong in ordinary Git history. ## Validation For a rendered file, run `scripts/validate_media.py` with the expected streams and dimensions. Also inspect representative frames at the beginning, every major transition, the mobile segment, and the end card. The validator cannot detect bad writing, visual obstruction, misleading footage, pronunciation problems, or live-state drift; check those separately.