The Auto-Overlay Tool: Motion Graphics I Don't Have to Prompt
The short version
Prompt-to-animation already works. On a long video the expensive part is finding the moments and writing a prompt for every one of them, so that is the part I automated. It runs on the Claude plan I already pay for, with no credit meter and no second transcription bill.
I already had a way to make motion graphics without hiring a designer or learning the craft myself. What I didn't have was a way to stop writing a prompt for every single one of them. On a long video that is the real work: watching it back, deciding which moments deserve a graphic, then describing each one, with its timing and its position, to an AI agent. So I built a skill that does that part for me. This page is how it works.
It runs on the plan you already pay for
There is no credit meter behind this. Higgsfield and Runway bill you per generation, which is the mental model most people bring to the words "AI animation", and it's the wrong one here. Nothing in this tool generates video out of a model. The graphics are drawn as code, rendered on my own machine, and dropped into CapCut. It runs on the Claude subscription I already have, and there is no second API bill anywhere in it, including for transcription.
Where this sits in the workflow
Two of the four post-recording stages run on their own, but neither is fully unattended: auto-cut asks me about the content before it publishes a draft, and auto-overlay stops once for me to approve the moments it found. The two stages at the ends are still mine.
Recording is the part I want my time going into. Everything after it used to be mine too, and now most of it isn't. What I want to be clear about is that the middle is not fully unattended, even though it's often drawn that way. Auto-cut asks me a round of questions about the content before it publishes a draft. Auto-overlay stops once, in the middle, for me to approve the moments it found. Two stops, both short, and neither of them optional.
The bottleneck was never the animation
Prompt-to-animation already works. HyperFrames is a free tool that takes a plain description of a graphic, how it should look, where it should come in from, where it should end up, and produces the animation. That on its own is already far easier than learning motion design or paying someone for it.
The problem shows up on a long video. You still have to watch it back, pick the moments, and write a prompt for each one. Prompting takes time and attention, and by the end of a long video you're not doing it as carefully as you were at the start. That fatigue is what I wanted gone, not the drawing.
What a prompt still needs
Three things, every time. It needs the description, which is what the graphic says and how it looks. It needs the timing, down to the second it appears and the second it leaves. And it needs the placement, because a graphic sitting over your talking-head bubble, or over the part of the slide you're pointing at, is worse than no graphic at all.
Describing is the easy one. Timing and placement are what send you back into the timeline to check, and they're why a prompt for a single graphic takes longer to write than it looks.
It reads the cut you actually made
The tool runs after you've finished hand-editing, not before. It opens the CapCut project and reads the timeline as it stands, and that timeline is the only thing it trusts for coordinates. Every position it produces is measured against the cut you actually made, which is why the graphics land on the footage rather than near it.
Finish your cut before you run this. One trim to the main video track after you've approved the moments moves everything downstream of it, so every approved position is now wrong and the run starts over from the beginning. The cost is real and it's worth knowing up front rather than discovering it.
The transcript moves, it's never transcribed twice
The cutting stage already paid for a transcription of the raw recording, every word with its own timing. After the cut those timings no longer line up, because the silences and the bad takes have been removed. The obvious fix is to export the new timeline and transcribe it again. This doesn't do that. It works out what was dropped and shifts the transcript it already has onto the new timeline.
Two reasons, and the first one matters more than the money. Transcription is a model call, so running it twice on the same audio doesn't reliably give you the same answer twice, and a word whose timing shifted is a graphic that lands late. Moving a transcript you already have is arithmetic, and arithmetic gives you the same answer every run. The second reason is that you already paid for it once.
Two passes look, then I decide
Running one pass twice gives you one opinion asked twice. Two passes dispatched independently give you two, and anything only one of them noticed still makes the list. Merging is the cheap part. Looking twice is what makes the list worth approving.
Finding the moments runs as two separate passes over the same material, dispatched independently, neither one seeing the other's answer. Whatever either pass found goes onto the list. Nothing gets dropped for having been found only once.
Running one pass and asking it twice is not the same thing, and this is the part worth copying if you build something like it. One pass asked twice gives you one opinion, restated. Two give you two, and the moments only one of them noticed are exactly the ones a single pass would have missed.
Then it stops. The list comes back with a number against each moment and I go through and say which to keep. That's the one human decision in the middle of the run, and it happens before anything is drawn, which is what makes saying no cheap.
Each graphic is drawn for its own moment
Nothing is picked out of a preset library. Each drawing task gets one moment, the brief written for it, and stills taken from its own stretch of the video, which is how it knows what the footage already shows and which corners to stay out of. Batches run at the same time, and a mechanical gate checks every result before it goes any further.
Nothing here is picked out of a preset library and nothing is filled into a template. Each approved moment gets its own drawing task, handed the brief written for that moment and stills pulled from that moment's own stretch of video. The stills are what let it see the footage underneath: which corner is empty, where the talking-head bubble sits, which part of the slide is being pointed at.
Several run at the same time, and then every result goes through a mechanical gate before it gets anywhere near the timeline. Most failures are repaired in place, meaning only the part that failed is redrawn. That matters because these are model outputs, so a redraw from scratch gives you a different graphic rather than a fixed one. A handful of failures deliberately never auto-repair and come to me instead, because a repair pointed at one of those would restyle something that was already correct.
Placed on a track the tool owns
Each graphic is rendered with a transparent background at your project's own resolution, then placed on separate tracks that belong to the tool. Re-running replaces that whole family rather than adding a second copy of it, and the clips you cut yourself are never touched.
CapCut works in video clips, so a graphic has to arrive as video. Each one is rendered with a transparent background at your project's own resolution and shape, because a graphic rendered at the wrong size lands in the wrong place.
They go onto tracks that belong to the tool, with a sound as each graphic arrives and another as it leaves. Your video track is read and never written to. Run the tool again and it replaces that whole family of graphics rather than stacking a second copy on top. If a redraw fails on a re-run, it refuses and changes nothing, instead of quietly removing a graphic you'd already accepted and watched.
Where it still needs me
This is the first working version, and there are three things I wouldn't call finished.
Legibility over busy footage. A graphic can be placed correctly, in genuinely empty space, and still be hard to read against a dark and wordy slide. That one still needs my eye.
Graphics that restate what's already on screen. If the slide underneath already says the thing, the graphic adds nothing and should be dropped. It doesn't always catch that.
The sounds are basic. Every graphic gets the same pop in and pop out. A panel sliding in from the left should get a slide, not a pop. That's a matter of widening the library and it's on the list.
Then there's the one that isn't a rough edge but a constraint you have to plan around: finish the cut before you approve the moments. One trim afterwards costs the whole approved list.
Get the blueprint
Everything above is the shape of it. The blueprint below is the architecture and the data flow in full: what goes into each stage, what comes out of it, and why each boundary sits where it does. It's deliberately not the code and not the decision rules. If you want to build your own version of this, it's enough to start from.