Changelog video from commits

The person points at their product's repo and a date range ("this week", since the last release). You deliver a ~40 s "what's new" video (16:9 1920×1080 or 9:16 1080×1920, 30 fps) for people who already use the product: a narrator, a light music bed, big type in the brand, and each change that matters shown happening on the app's own screens. No presenter and no generated footage, so the only paid parts are the voice and the music, and the next week's video is the same build script on new facts.

How it differs from its siblings: workflow-product-explainer-video sells the product to someone new (pain, steps, proof) on its marketing screenshots; workflow-launch-video gives one feature the whole video. Here the viewer knows the app, so there is no pitch: the hook is how much shipped, and every beat is a change they will notice next time they open it.

Record the brief, the date range, the approved script and the picks where you keep the job's notes; rounds and deliverables follow the core skill.

Steps

1. Read the range (guide-pull-product-highlights, the GitHub repo route, with the clone's own log): every commit in the range with its date, author and subject in source/commits-<from>_to_<to>.txt, and the count of commits, files and lines changed. Write source/facts.md grouped by area (the biggest first), each change in the user's words with its commit, and an "Internal (not for the video)" group for tests, analytics, build paths and refactors. Read the diff behind any subject you can't explain to a user.
2. Brand and the app's own look (guide-capture-a-brand): the brand's colours, fonts and mascot, and an earlier video or teaser if the person has one (its look is the first candidate). From the UI code, the app's palette (its theme file) and the layout of every screen a beat will show: these are rebuilt, not screenshotted.
3. Script and beats (llm-write-an-ad-script, rules for type and voice): the count as the hook ("Forty-two changes landed this week. Here are the ones you'll feel."), then three or four numbered areas with one or two changes each, said as what the user can now do, then "Plus:" and three small ones in a breath, then a one-line sign-off. About 120 words for 40 s at an upbeat pace. Keep the spoken text with respellings (an acronym spelled out letter by letter, "A-C-M-E") in its own work/narration.txt, so the script and the type keep the real spelling. Pair it with a beat table: time, picture, on-screen text. Gate: the script and beat table as one .md in review_approve, with the aspect and the job folder as questions.
4. The first scene, the voices and the music, all at once. Start three narrators on the whole narration (guide-voice-a-script, A narrator for a short) and two beds of the video's length (elevenlabs-generate-music, Fit the bed to the cut). While they run, build the hook scene in three looks (hn4a-compositor, The first look) on word times estimated from the script (python-read-word-timings), with the build script of step 5, so the pick carries straight over.
5. The first reviews (core skill, Reviews): the looks as review_choose, and the narrators and beds as audio options as they land. Gate: a look, a voice, a bed if they can pick one.
6. Build the whole layout in the picked look, cued to the picked take (hn4a-compositor, references/build-script.md): one build script that takes <alignment> <voice> <music> <out spec> --look <pick> and finds every cue by phrase in the take's own alignment, entrances 0.12 s before their word. The scenes:
   • Hook: the count slams in; the range's real commit subjects scroll past as a ticker behind it, the ones the video covers lit in the accent.
   • Each area: a numbered kicker (01 · AREA) and a two-to-four-word headline on the left; on the right the app's screen rebuilt as layers (hn4a-compositor-rebuild-product-screen), doing the change on its words: a line edited and the button relabelling, the top card of a stack sending and the next sliding up, a progress bar stuck at 0% until a timer ring runs out and it turns red. Pills in the accent name the change in two or three words.
   • A feature of a visual tool is shown by using it: a title laid on a street for a perspective feature (hn4a-compositor-perspective-planes).
   • Plus: three tiles in a row, one per small change, popping on their words.
   • End card: the mascot, the product's name, "this week" and the range. Check the take against the script (whisper-cli-transcribe-with-word-times, Check it): every word, no tag spoken. Sheet a still inside every scene (python-contact-sheet) and fix what it shows. Gate: the live spec (hn4a-compositor, Live spec, then render); if the music is unpicked, one spec per bed as the options.
7. Render and deliver. Voice to −16 LUFS (ffmpeg-normalize-loudness), the bed under it at about 0.16, hn4a-compositor render, then measure the render's loudness before delivering it per the core skill (When it's done).

Choices this workflow makes

• Only what a user will feel. A week's log is mostly fixes, tests and plumbing; the video picks five or six changes and lists three more, and says nothing about the rest beyond the count.
• The count as the hook, with the real subjects behind it: it says "a lot shipped" without a claim the log can't back.
• The app's screens rebuilt from its UI code, not screenshots: this week's changes aren't in any marketing screenshot yet, the theme file gives exact colours, and a rebuilt screen can perform the change on its word. The data on them is invented and neutral.
• Grouped by area with numbered kickers, so a viewer can tell where in the app each change lives.
• The build script is the template. The looks, the cues and each scene are functions of the facts and the take, so next week is new facts, a new script and a re-run.

Dead ends

• Plane groups drawn flat: on this job the installed compositor ignored plane and drew the street title flat. Check one plane still before building on it; the street was rebuilt as a CSS perspective on the group's inner html.
• A mono voice made stereo for the mix measured about 3 dB louder in the render: it came out at −13.2 LUFS. Measure every render; fixed with −3.2 dB on the audio alone, the video stream copied.
• whisper run on the music beds to check for vocals heard "Music playing" across whole 30 s windows: a hallucination, not singing.
• ffmpeg with several inputs and outputs without a -map per output gave every output the first input.

Worked example

Acme Co.'s desktop app, one week: 42 commits, 152 files, +5,045 / −795 lines, four areas worth showing and a dozen internal changes left out. 16:9 1920×1080, 30 fps. Script 124 spoken words, approved as drafted. Brand: blue #2210D8, lime #70EE48, near-black #121312, Brand Sans ExtraBold headlines, a pixel face for kickers, a halftone mascot. Spec: 7 scenes, 149 layers, 39.0 s.

Three looks of the hook on estimated times: A bold pop (dotted near-black, white type with a hard blue shadow, lime pills; the brand's teaser look), B electric blue (solid blue, hard black card offsets, wipes), C clean app (the app's light ground, calm fades). The person left the look to us: A, to match the teaser. Three narrator auditions of the whole narration: 37.4–38.3 s; Voice A picked (37.4 s). Two beds, electronic and warm lo-fi; the warm one picked from two live specs. The whole spec was approved with no notes; the render came out 3 dB hot and was fixed on the audio alone. About $0.47 in all (3 auditions, 2 beds); stills and renders are free.