A subtitle-to-video pipeline that splits the work between two agents

Two agents assigned to jobs each is actually good at

This is a workflow template that turns a subtitle file into a finished vertical motion-graphics video, using two different coding agents for two different halves of the job. You supply a transcript as an SRT file, and the pipeline splits it into shots, generates an animated clip for each one, and stitches the results into a final video with FFmpeg.

The interesting decision is the division of labour between the two agents. Codex acts as the scheduler: it reads the transcript, splits it into shots by meaning, creates a directory for each shot, and calls the second agent once per shot in sequence. Claude Code is the one that actually writes the HTML animation project for each shot and renders it to video.

That split maps cleanly onto what each agent is being asked to do. Reading a transcript, deciding where natural shot boundaries fall, and orchestrating a sequence of calls is a planning and control-flow task. Writing an animation project against a documented framework and getting it to render correctly is an implementation task. Assigning a specialised planner to the first and a specialised coder to the second, rather than asking one agent to do both, is a sound piece of tool selection, and it is the kind of decision that only becomes obvious once someone has actually tried making one agent do everything.

Why sequential rendering, one clip at a time, is the correct call

The README states a rule plainly in its notes: only one Claude Code call runs at a time, and shots are never rendered in parallel. On first read that looks like it is leaving speed on the table, since generating several shots simultaneously would obviously finish faster.

It is the right constraint anyway, for a reason the architecture itself makes clear. Each shot-generation call is a full coding session: writing an HTML animation project against a documented set of components, then rendering it to a fixed resolution and frame rate. A single one of these can run for a long time, and the README's own evidence section documents a real run that continued for one hour and thirty-six minutes with Codex waiting on Claude Code to finish a shot's implementation and render.

Running several of those long sessions in parallel multiplies resource contention, log interleaving and the chance that one failing shot's output gets confused with another's, for a task that is already tolerant of taking a while since there is no human waiting synchronously on each shot. Trading a highly parallelisable render for a serial, easier-to-diagnose one is the same trade a careful engineer makes in a batch pipeline where correctness and debuggability matter more than wall-clock time.

Making a video pipeline testable end to end

Automated video generation is a notoriously hard thing to test, because the obvious failure modes, a shot that renders at the wrong resolution, a video that gained an unwanted audio track, a duration that drifts from the source transcript, do not throw an exception. They just quietly produce a wrong-looking file that a human has to notice by watching it.

This project answers that with a dedicated end-to-end test harness rather than leaving verification to eyeballing the output. A test script builds a temporary workspace, copies in a test transcript and the shot template, runs the full pipeline through Codex, and then a separate validation script checks that every expected stage-completion message from Claude Code actually appeared, that both the per-shot files and the final stitched video exist, that the video is the correct resolution, that the frame rate is close to the target, that the total duration tracks the source transcript's length, and that no audio track crept in.

Turning "does the video look right" into six specific, scriptable assertions is a real piece of engineering discipline for a domain where most projects settle for a demo GIF and hope. It also means a contributor changing the shot-generation template has an actual regression test to run rather than a rendering they eyeball once and hope keeps working.

A flag combination worth reading twice before typing

The quick-start command is where a user should slow down rather than copy and paste immediately:

codex exec \
  --cd . \
  --sandbox danger-full-access \
  --ask-for-approval never \
  - < PROMPT.md

Each flag there is doing something specific and consequential. The sandbox flag grants full access rather than a restricted execution environment, and the approval flag means Codex will not pause to ask before taking an action, for the entire duration of the run. Combined, this is an agent given full permissions and no checkpoint to stop it acting on its own, running for however long a multi-shot video takes, which the README's own evidence shows can be well over an hour and involves a networked environment for fetching brand assets and installing dependencies along the way.

None of that is unreasonable for what the workflow is trying to do; an agent writing and rendering animation code across many shots genuinely needs broad permissions to work unattended for that long, and asking for approval before every file write would make an hour-long unattended run impossible. It is, however, exactly the kind of command that deserves to be run in a disposable environment, such as a container or a scratch checkout, rather than directly against a machine holding anything you would mind an unattended, fully permitted agent touching for ninety minutes.

A skills folder is the actual animation knowledge

The animation layer itself is not built into the orchestration scripts. It lives in a skills directory inside the example folder, described as HyperFrames-related skills that Claude Code draws on to write each shot's HTML animation project before rendering it to a fixed 1080 by 1440 resolution at 30 frames per second, silent, with no audio track.

Keeping the animation knowledge as a skill Claude Code loads, rather than hard-coding a specific animation approach into the pipeline scripts, is a sensible separation. The orchestration layer's job is scheduling and stitching, and it does not need to know or care what the animation framework underneath actually is. That also means the quality and range of the generated motion graphics depends entirely on what is inside that skills directory, and improving the visual results going forward is a matter of refining those skill documents rather than touching the scheduling logic at all.

The fixed portrait resolution and silent output are consistent design choices for the stated use case, a short-form vertical video meant to carry narration or music added separately, rather than a video expected to carry its own audio track.

What to check before running it

The prerequisites are substantial and worth confirming before attempting a run rather than discovering mid-way: both agent command-line tools installed and authenticated, Node.js 22 or newer, FFmpeg and its probing companion, a JSON command-line processor, and network access, since Claude Code may need to search for material, install dependencies or fetch brand visual assets during a run. The README gives a short set of version-check commands to confirm all of this is present before starting.

The repository has no stated licence, which anyone planning to build on it or redistribute it should raise with the maintainer directly rather than assume permissively. This is not legal advice. It reports 319 stars, 41 forks and two open issues, with the last push on 2026-07-23 and no tagged releases, so the default branch is what anyone adopting it will be running.

Before starting a real run, three steps in order. Run the built-in end-to-end test first against the bundled test transcript, so you see a full pass with all six checks before trusting it on real content. Run the unattended, full-access command inside a disposable environment rather than directly on a machine you care about, since the whole point of that flag combination is a long unattended session with no approval checkpoints. And if a shot fails partway through, go to that shot's own log files first, since the README points there specifically rather than at the overall run output.

Editorial conclusion

This pipeline fits someone comfortable running two coding agents unattended who wants a repeatable way to turn a subtitle transcript into a stitched, silent, vertical motion-graphics video, and its division of labour, a planner splitting shots and a coder rendering each one in sequence, reflects a genuinely sound choice of which agent does which job. Its built-in end-to-end test, checking six concrete properties of the output rather than relying on a human watching the result, is the strongest engineering signal here and worth running against the bundled test transcript before any real content. Treat the quick-start command's full-access, no-approval flags as exactly what they are, an agent left unattended for potentially over an hour with broad permissions, and run it in a disposable environment rather than against anything you would mind it touching.

Frequently asked questions

Official sources

1. Issues
2. README
3. vibe-motion/auto-motion on GitHub