launch_video_production v1.0.0

name: launch_video_production description: "Make a product launch video in code, tool-neutral: pick the video type from the launch size (teaser, kinetic announcement, UI hero reveal, feature drop, roundup, before and after, milestone), rebuild product screens with fictional data under honest claim rules, fit storyboard and voiceover to the music beat, and run a render QA pass. Use when a product, feature, version, or milestone is launching and needs a launch video built from code scenes rather than screen recording or live footage."

Launch Video Production

Purpose

Turn a launch into one video that is sized right for what actually shipped, built from code scenes, and honest about every line it carries. This skill covers the full job: choose the type, rebuild the screens, write and time the voiceover against the beat, render in any seekable code video stack, and pass a QA gate before the video ships. It is tool-neutral on purpose: no single render stack and no single voice service is required, and nothing in the workflow breaks when either one changes. For live screen recording of a working demo, use a demo video skill instead. For batch rendering many variants of one template, use a programmatic video skill. For the announcement sequence around the video, use a launch announcements skill.

Workflow

1. Write the launch facts first. Product name, what changed in one sentence, who it is for, launch date, where the video will run, and what a viewer should do after watching. If the one sentence names three changes, the launch is a major version or a roundup. If it names no visible change, the launch is announcement-only and that decides the type before any art direction starts.
2. Pick the type from the launch size. Use references/type-decision-matrix.md: patch gets a before-and-after, single feature gets a feature drop, major version gets a UI hero reveal or a roundup, new product gets a UI hero reveal, a checkable number gets a milestone video, and news with no visual change gets a kinetic announcement or a teaser. A video bigger than the launch is the most common failure in this job.
3. List every claim before writing a line. Spoken lines, on-screen lines, pricing, dates, in-frame numbers, and any customer line all go on one claim list, each with the evidence that backs it: a release build check, a pricing page, a measurement with its method, a real customer quote with permission. Standards and worked rules are in references/fictional-ui-and-claims.md. A claim with no evidence gets cut or rewritten as a mechanics line, what the thing does, with no result attached.
4. Rebuild the screens the video shows. Work from screenshots of the shipped build, never from design files alone. Rebuild only the surfaces the scenes use, freeze a state list for each scene, and time rebuilt transitions against the real build so the video never shows the product faster than it is. Fill the screens with fictional data under the placeholder rules in the same reference: invented names, placeholder shaped numbers for metrics, sample content that shows mechanics, and no fictional results.
5. Build the plan file and run the planner. Write a plan JSON in the shape of the samples in assets/ and run scripts/plan_launch_video.py plan.json --out storyboard.md. It checks the type against the launch size, fails the two hard bans (a screen reveal or a before-and-after for a launch with no visual change, a hero reveal for a patch), builds scenes from the type template when the plan has none, counts the voiceover against its word budget, fails any claim with no evidence entry, and reports cuts that sit off the beat. Fix the plan until it prints plan OK. Warnings need a written reason in the plan notes or a change of type.
6. Write the voiceover to the budget, then record or generate it, then re-fit. Planning pace is 140 words per minute for launch narration, and the planner holds back 10 percent of the runtime for pauses, so a 60 second video budgets 126 words. Write short sentences, one idea each, numbers written as they are spoken. Then get the actual voice, by recording or by any voice service, measure its real duration per line, and move scene boundaries to the voice. The voice never gets squeezed to fit scenes drawn before it existed.
7. Fit cuts to the beat. Pick the music before the final storyboard pass. At a given bpm, one beat lasts 60 divided by bpm seconds. Scene turns and major text landings sit on beats or on bars, planner notes flag cuts that miss, and the fix is a small share change in the storyboard. Beat fitting serves the reading speed of the text: a line a viewer cannot finish reading is cut or held longer, even when the beat says move.
8. Build scenes as code, seekable and deterministic. Use any code video stack the team already runs, HTML or React compositions, vector animation tools, Python compositing, or FFmpeg assembled scenes, as long as each frame is a function of time and data so a single frame can be re-rendered alone and the render can be reproduced. Keep text, timing, theme, and assets as separate inputs to the scenes. A change to a line of copy must never require touching animation code.
9. Render the wide master and any planned cuts. Default master is 1920 by 1080 at the project frame rate. A vertical cut, when the launch plan calls for one, is a planned second render with its own reframed scenes and its own storyboard check, not a centre crop of the master done at export time.
10. Run the render QA pass. Follow references/render-qa.md on the final file: format and bitrate against the plan, a full silent watch, a full-size still per scene read as a stranger, contrast and flash checks, a fictional data pause check on every screen, loudness measured, captions read against the actual audio, and the package saved with its claim list and evidence. One named person signs off in writing before the video posts.
11. Check launch results one week after posting. Record where it ran, views, completion or watch time where reported, clicks on the launch link where countable, and one plain sentence on what the video did or did not do. File it with the project. The next launch picks its type and size from real past results as well as from the matrix.

Output Contract

• A plan JSON that passes scripts/plan_launch_video.py with no errors, plus its generated storyboard timing sheet with scene starts, ends, visuals, voiceover lines, and on-screen text.
• The claim list for the video, every claim paired with its evidence entry, saved with the project.
• The finished video file at the planned size, frame rate, and duration, plus any planned vertical cut as its own render.
• A caption file timed to the actual voice, and the script as actually spoken.
• A signed-off QA record from references/render-qa.md and a dated launch results note filed one week after posting.

Operating Rules

• Size the video to the launch, never to the maker's excitement. Two real changes padded into a roundup of five reads as two real changes said louder, and viewers price the whole channel down for it.
• Tool-neutral is a hard rule. The plan, storyboard, claim list, and QA record must survive a change of render stack or voice service with no rework. Any step that only works in one named tool gets rewritten until it works in the family's plain terms.
• Rebuilt screens are claims. A screen rebuilt from a design file the build has not reached, a transition faster than the real product, or a dashboard number invented to look live all state things the launch cannot back. The fictional data rules in references/fictional-ui-and-claims.md are the line, and crossing it fails QA, not just taste.
• Voice timing comes from the actual recording. The 140 words per minute figure is a planning number for the script budget. After the voice exists, its measured timing is the only timing the storyboard may use.
• Loudness is stated honestly. The house master is minus 16 LUFS integrated, true peak at or below minus 1 dBTP, measured per ITU-R BS.1770, and it is a house rule for one file that travels everywhere. YouTube publishes no reference loudness level for uploads, and EBU R 128 at minus 23 LUFS is a broadcast delivery standard. Never present any of the three as either of the others.
• Format facts used in QA come from YouTube's recommended upload encoding guidance: MP4 container, H.264 video, AAC audio, source frame rate kept, and SDR upload bitrates of 8 Mbps at 1080p standard frame rate, 12 Mbps at 1080p high frame rate, and 5 Mbps at 720p standard frame rate. Recheck the guidance when a platform changes its page, and never quote the numbers from memory in a QA sign-off.
• Accessibility checks are pass or fail, not polish. On-screen text meets WCAG 2.2 AA contrast, at least 4.5 to 1 for normal text and 3 to 1 for large text. Nothing flashes more than three times in any one second. Captions cover all speech in the posted file, read line by line against the audio by a person.
• Every factual number in a skill output needs its source in the plan or the QA record. Percentages without a base and date, user counts without a checkable source, and dates the release plan calls hopes all fail the claim check the same way an invented metric does.
• Worked examples live in references/worked-examples.md, with full passing plans and storyboards for a 30 second feature drop, a 60 second roundup, and a 75 second hero reveal in assets/. All sample products there are fictional and their data is placeholder, which is the fictional data rule applied to the skill itself.