One-shot launch videos: what the skill decides, what the model writes

mdjsonmcpcopy↗ai

2026-09-26 · 18 min · explainer · agents · open-source · code-generation · audio · video

Three GitHub links went round this week as launch videos that Claude made in one shot. The first, latent-spaces/brag, was pitched as a skill that "analyzes your repo and outputs a complete motion-graphics teaser with sound design and launch copy in a single run." The second, arimanyus/hophopnopenope, is "the code behind the coderabbit music video", a 128-second cartoon about a code-review rabbit whose comments nobody reads. The third, arimanyus/warrenduffer, came from the same author two days earlier and is not a video: it is an MIT-licensed trading bot, 54 tracked files, none about pictures or sound. I leave it there.

I cloned the other two, read every text file, counted lines and assets, and walked the git history. I did not run their code. Every number is labelled: measured (I counted it), reported (the repo or its author says so) or reasoned (I derived it; check my working).

The short version: "one shot" names the last step. What sits under that step differs by two orders of magnitude, and that is where the engineering is.

The shape they share

Strip the branding and both repos run the same five-stage pipeline (reasoned from the code; /brag-slim leaves the tools open but assumes the same shape):

1. Read something: a project's pages and stylesheet, or a song.
2. Write a plan to a file: a storyboard with scenes and durations.
3. Write code that paints frame n as a pure function of time.
4. Drive a headless browser to call that code once per frame and save the picture.
5. Hand the frames and an audio track to ffmpeg, which muxes them into an MP4.

No image or video model draws anything; the music video's README says so outright. What differs is who writes stage 3, where the audio comes from, and which clock is the master.

/brag: a skill that writes a brief

/brag is a Claude Code plugin (version 0.4.0) by Shunit Haviv Hakimi. The skill is a 179-line SKILL.md plus six reference files of 1,283 lines, so the agent is handed 1,462 lines of instructions (measured). It runs four steps, each ending in a gate.

Inspect. The agent reads in a fixed order: index.html in full, the stylesheet (CSS custom properties become the exact brand colours), README.md, package.json, routes and components, then the user flow as three beats, "entry → key action → result". It skips lock files, .env files and key material under a rule titled "nothing secret leaves this step", because anything read here can end up on screen. The gate is a nine-question rubric: what the app is, its funniest claim, the visual hook, which real UI to show, the shortest satisfying length, tone, audio, share caption, and the user flow.

Plan. It writes brag-plan.md: angle, hook, two or three highlights, punchline, one of seven tone presets, exact colours and fonts, audio direction, and a storyboard where every scene carries a duration, its text, an audio intent and a transition. The gate is arithmetic: durations must sum to 15–25 s. A reading-time floor holds a short label about 0.8 s and a sentence about 0.3 s per word, because pace should come "from fast motion, fast transitions, and tight cuts — NOT from pulling text off screen before it can be read."

Brief. It writes composition-brief.md and loads five skills from Hyperframes, HeyGen's Apache-2.0 framework for rendering HTML to video. /brag owns "the product angle, source material, storyboard, tone, format, audio selection"; Hyperframes owns "the concrete composition structure, exact animation timing, animation mechanics". The gate is npx hyperframes check with zero errors: lint, layout overflow, and WCAG contrast as an error, not a warning.

Deliver. Render brag.mp4, pick a poster from the strongest settled beat, and bake it into frame 0 with an ffmpeg overlay (enable='eq(n,0)'), because "Slack, Twitter/X, and Discord regenerate thumbnails server-side and ignore embedded cover-art metadata." At 30 fps the poster shows for 1/30 s. Then write share-copy.txt.

expand

How it picks what to show

The planning reference ranks four ways to fill a scene: recreate a working-app moment ("the product doing its thing beats the product describing its thing"), recreate one UI element in HTML, animate the core concept, or let the copy be the visual. It bans "abstract patterns, color washes, or generic motion graphics that could belong to any video."

The repo ships five absurd product sites in examples/ as a benchmark, each with its render. The five renders run 20 to 23 seconds at 1920x1080 and 30 fps (measured with ffprobe). One input and its output:

expand

expand

The shape is the skill's pattern and the material is the site's: the taxi numbers #4821 and #2207, the 3:08 ETA and the testimonial are verbatim from index.html (measured). The hook line is not on the site. It is the worked example of share copy in the skill's own step-4-deliver.md. Both arrived in the first commit on 2026-06-16, so I cannot tell which informed which, but the benchmark's best line is printed in the prompt.

The render stacks

None of them uses Remotion, Three.js, Tone.js or the Web Audio API (measured, case-insensitive search of every tracked text file). GSAP enters /brag only through the framework, whose core skill requires "exactly one gsap.timeline({ paused: true })" per composition and bans render-time clocks, unseeded Math.random and network access. That is what lets a headless browser seek to any frame and get the same picture twice.

The music video's render.mjs is 78 lines. It calls window.renderAt(t) in several Chrome pages at once, writes JPEGs into out/frames, skips frames already on disk so a crashed render resumes, and encodes x264 at CRF 16 with the song as 256 kbit/s AAC. At 24 fps its 128.64 s come to 3,087 frames (reasoned from the frame loop).

Keeping time with the audio

/brag: the music is a cue sheet

The five bundled tracks each ship a precomputed cue preset, generated by a 309-line analyze_music_cues.py that uses librosa's onset strength, RMS loudness, a 30–180 Hz bass band and its beat tracker. A preset holds a tempo, a beat grid and 64 strongCues per track (measured). The rules are tolerances: a major reveal may move toward a strong cue by ±0.15 s, a smaller entrance may snap to a beat within ±0.10 s, a video gets one to three strong locks, and readability wins every conflict. At 110+ BPM, text that must be read snaps to every other beat or holds as a set, a rule the file traces to a benchmark whose sequence "rushed the bicycles spec rows."

The audio sits inside the composition as <audio data-start data-track-index data-volume> clips, music at 0.3–0.4 and effects at 0.55–0.85. The framework owns media playback, so sound and animation read one timeline.

The music video: measure the song, then read the tables

Here the song came first, and tools/ is a small forced-alignment pipeline (measured, reading the scripts):

1. Demucs splits vocals from band; both stems are committed, two 22.7 MB WAVs.
2. transcribe.py runs faster-whisper large-v3 through stable-ts on the vocal stem.
3. align.py force-aligns the 32 known lyric lines, word by word.
4. transcribe_windows.py re-transcribes short windows, because "whole-song passes skip the ad-lib tags".
5. refine.py snaps hit words (hop, nope, click, tick) to the strongest vocal onset within 0.18 s and measures held notes with pYIN.
6. finalize.py applies 12 "Hand-checked fixes"; build_data.mjs bakes the tables into src/data.js.

The result is 32 lines, 239 word onsets and 301 tracked beats at about 142.2 BPM, with a warning that the grid drifts up to about 0.13 s from a constant tempo.

The author's post says "the alignment also found a sung 'as mentioned above' at 2:00 that wasn't in the lyric sheet." The data has it at 120.0–122.25 s. One precision: forced alignment only places words you hand it, and refine.py credits those three words to the per-window pass. The post also says its template's karaoke "estimates word timing from line length". That checks out: the template times whole lines from burned-in subtitles and fills letters at a fixed rate, the sung duration being the smaller of the line length minus 0.1 s and 0.45 s + 0.075 s per character.

Two rules turn the tables into sync. Cuts snap "to the frame that contains their time, so a cut on a downbeat is never late." And every beat and hit helper looks one frame ahead (VLEAD = 1 / 24), the "sync law": "a visual hit lands on the frame of the sound or one frame early, never late." In preview the <audio> element's currentTime drives the drawing; in the render the frame number does.

The chapter files register 85 shots in 8 chapters. The mean shot lasts 1.51 s, the median 1.42 s; the shortest is 0.17 s before the opening stab, the longest the intro's 4.92 s fall (measured). Of the 85 cuts, 72 land within 50 ms of a tracked beat or a measured word onset, allowing for the one-frame lead: 36 near a beat, 55 near a word. A random cut manages that about 51% of the time, so the alignment is deliberate, not total (measured over 200,000 random times).

Sound design: bought, made, or sung

/brag buys it. It bundles 260 effect files, 3.1 MB: 51 card and chip sounds, 109 impacts, 20 interface sounds, 48 clicks and switches, 32 keypresses (measured), all CC0, mostly Kenney's. A generated sfx-analysis.md scores each for "high-frequency risk" so the agent keeps harsh sounds off anything that repeats. Music is five tracks from ende.app, 13 MB. Narration is opt-in: --voice runs Kokoro through npx hyperframes tts and ducks the music to 0.12–0.15.

/brag-slim makes it. No assets. The one sound instruction: "Write the music and sound effects as one piece: effects in the same key and the same space as the music, blended in rather than laid on top." With nothing bundled, the model must synthesise or source the score with what the machine has (reasoned; the skill does not say how). Its demo is 22.5 s of 1080x1080 video with AAC audio (measured).

The music video sings it. The audio is the finished song; a tools comment mentions "the unlisted Suno tags", placing its origin in a music generator (reported). render.mjs muxes exactly one audio input, so no effects are added (measured).

What "one shot" measures

All measured. The Hyperframes figure is a ceiling: its reference files are read on demand.

For /brag, one shot is literal at run time: one command, four gates. But the skill has a hundred days of commits behind it, growing from 1,395 lines of instructions to 1,462 and picking up the best-beat poster, the frame-0 bake, the secrets rule and narration. The full skill now hands off to /brag-slim on its own when it detects one particular newer model, unless the user asks for the full workflow or for narration. The maintainer's bet, then, is that one model needs 101 lines and no assets while every other model gets 1,462 lines, 260 sound files and a framework. The generated half, the composition written on each run, is never committed, so I cannot measure it.

For the music video, the history reads like an orchestrated build on 2026-09-24. At 18:02, only the song, stems and timing data. At 18:38, 754 lines of shared library and eight chapter files of one line each. At 19:46, seven chapters with code, 3,438 lines, and the intro still a stub. At 20:14, a commit titled "subagent 2/8 completed", all eight, 4,699 lines. At 21:51, "full code", 4,819. The animation guide tells each chapter author "Only edit your own chapter file", to report shared-file bugs "in your final message", and to check contact sheets before finishing: a brief for parallel sub-agents. The template's README says its own guide was written "to brief the subagents it ran in parallel" (reported). So one shot here means one session: an orchestrator, eight chapter agents and at least four checkpoints (reasoned).

The music video: whose template

The post credits the template to two creators' earlier videos. The README credits one project, JohnHeibel/PDoomVideo, and its shape: "a storyboard, then a shared drawing library and character rig, then one file per chapter, then a frame render, then an ffmpeg mux." I could not map the post's two handles to repositories, so I measured against the one the README names. The layout matches file for file. Identical non-blank lines, in order:

The render driver and page are inherited; the drawing is new. The template paints watercolour with p5.brush. The music video depends on puppeteer-core alone and prints riso in plain Canvas 2D: named inks, halftone instead of gradients, colour plates offset for depth, outlines that re-seed ("boil") 12 times a second, characters on twos and cameras on ones. That is the swap the post describes.

What is hand-authored, git cannot say. All six commits come from one account, and the README makes no claim, while the template's README says everything in it was generated. "Hand-checked" timing fixes are not necessarily hand-typed. The certainly external pieces are the song, the fonts and the pattern. That pattern has a descendant this site vendors: the template's README points to John Heibel's Claude Animation Base, which lives in brand-crew/skills/claude-animation-base/.

Licences

• /brag is MIT, copyright 2026 Shunit Haviv Hakimi, and its effects are CC0. Its music is not covered: the repo's assets/music/README.md says "Before publishing or redistributing the skill, verify and document the exact music license terms alongside these files," and no terms are committed (measured). So 13 MB of the plugin ships under undocumented terms.
• Hyperframes is Apache-2.0.
• The music video has no LICENSE file: default copyright, no grant to reuse. It also commits the song twice, 45 MB of separated stems (its .gitignore arrived one commit after them), and ten fonts, 22 MB, without their licence texts. So this page shows no frames from it; the widget carries its timing tables, not its pictures or lyrics.
• PDoomVideo has no LICENSE file either. Claude Animation Base and warrenduffer are MIT.

Every image here comes from /brag's MIT-licensed repo.

Against this site's own films

This site makes two kinds of film, one on each side of the divide.

The hand-drawn ones, like the narrated film opening the Kalman filter article, are per-film code: the vendored hand-drawn-canvas-animation skill has the model write one Canvas 2D file per film over a shared core, with a generated Web Audio score. That is the music video's design.

The explainer films, like the one on the figures4papers audit, are the other design. The model writes only data: a storyboard in data/films/<slug>.json, built from 15 scene types with at most 280 words of narration. A fixed engine of about 4,400 lines (measured) owns the rest: eighteen drawn styles, the motion, the host, the Kokoro voice, and a score audio.py synthesises from sine waves, noise and a plucked-string model. Sync is the engine's problem: it made the score, so it knows the beat grid and rounds every scene up to the next beat.

• A storyboard can be checked. pnpm validate:films fails when a digit in the film is not in the article, a quote is not verbatim or diagram nodes collide, and a hash marks a film stale when its inputs change. The music video's 4,819 lines of chapter code have no such spec, only a prose storyboard and contact sheets.
• A storyboard is bounded. Fifteen scene types cannot express a rabbit buried under four hundred comment-bunnies on twos. Per-film code can express anything the model can write, which is the point and also the review burden.
• /brag sits between. It fixes the story contract and generates the implementation inside a framework whose contract a linter checks before anything renders.

Nothing in any of these repos scores a finished video except the person watching it; for what judging generated brushwork takes, see the article on a model that paints in p5.brush.

What I would take from each

• Measure the audio before animating to it. Forced-alignment word onsets beat a formula on line length, and a one-frame lead keeps every hit on or before its sound.
• Gate before the render. /brag's nine questions, its 15–25 s sum and its contrast check are cheap. A failed render is not.
• Bake the poster into frame 0. One ffmpeg filter, and in the skill's words "the only reliable way to control the idle image everywhere".
• Licences before assets. One repo ships 13 MB of music under terms its own README calls unverified; the other has no licence at all.

"One shot" is accurate about the final run. It is silent about the 1,462 lines, the 260 sound files, the framework, the aligned song and the eight sub-agents behind it. Those are the parts worth copying.