motion-graphics: video editing skills you install into a coding agent

Six skills that each do exactly one job

The premise is stated in one line: free video-editing skills for Claude Code, where each skill does one job. The repository is a skills collection rather than an application. There is no library to import, no server to run and no model to download.

The six skills cover distinct pieces of an editing workflow:

motion-broll takes a video and a transcript and makes motion graphic B-roll timed to your words. object-separation separates a person, a product or a hand from the background in a video, on your own computer. explainer-high-energy produces a 12 to 20 second hype promo with beat-locked kinetic type and shape transitions. explainer-default produces a clean 45 to 90 second product demo, with the product's UI rebuilt and filmed up close while it is used. explainer-engaging produces a 10 to 30 second one-take story in which one element travels through the product's workflow. sound-effects adds real sound effects timed to the beat and measured, so it does not sound like cheap beeps.

The audience is a creator working with an AI coding agent who wants the agent to know how to do video work in a specific way. The alternative audience, an automation engineer, is served less well, and the reason is what the artifacts actually are.

Each skill has its own README under skills/, and the top-level README links to each of them as the full guide.

Install with one command or copy a folder

The install path is a single command:

npx skills add Barty-Bart/motion-graphics

After that you pick the skills you want. The README notes that it works in Claude Code and in other agents that read skills, which is the point of the skills format rather than a Claude Code specific script.

If you would rather not use the installer, the fallback is to copy a skill's folder from skills/ into .claude/skills/. That directory layout is worth noting for anyone deciding how to manage these in a repository: a skill is a directory, and the agent reads it from there.

The trade-off between the two approaches is version control. With the installer you get an explicit add step and a chosen set of skills. With a copied folder you get the skill under your own version control, which is what you want if you intend to edit it, since the point of a skill is that it is instructions the agent follows and those instructions often need to match your own house style, your footage and your delivery specs.

The repository also ships a docs/ directory with the demonstration gifs that the README embeds, one per skill, and each showing the before and after of that skill's effect.

motion-broll and object-separation work on your footage

Two of the skills operate on footage you already have rather than on a synthetic animation.

motion-broll is the more interesting one. It takes a video and a transcript and produces motion graphic B-roll timed to your words, which means the transcript is not decoration but the timing source. The agent needs to know where each phrase lands in time and then place graphic elements against it. The example in the repository is a cutaway graphic timed to speech, and the full guide lives in the skill's own README.

object-separation takes a different route. It separates a person, a product or a hand from the background in a video, and the README is explicit that this runs on your own computer. The demo gif shows the original footage beside the same footage with the speaker separated onto a new background, which is the compositing step that makes the separated subject usable in a new scene.

The distinction matters for expectations. motion-broll produces new graphic elements, while object-separation produces a cut-out you can composite. Both are described in one line each in the top-level README, so the per-skill READMEs are where the actual procedure, the tools used and the failure cases would be, and they are the files to read before you plan a project around a skill.

Three explainer formats with fixed lengths

The three explainer skills are templates with a specified duration and a specified narrative shape, and they differ in more than length.

explainer-high-energy is a 12 to 20 second hype promo with beat-locked kinetic type and shape transitions. Beat-locked means the graphics land on the beat, and kinetic type means the text moves, so the timing is the craft rather than the copy.

explainer-default is a 45 to 90 second product demo, and its distinguishing move is that the product's UI is rebuilt and filmed up close while it is used, which is a reconstruction rather than a screen recording.

explainer-engaging is a 10 to 30 second one-take story in which one element travels through the product's workflow, so a single visual thread carries the narrative.

Having three formats with fixed durations is the useful structural decision here. A skill that says make an explainer video leaves the agent guessing about length and pacing, and an agent that guesses produces something you will redo. The numbers in the table are the contract: the agent knows how long the piece is supposed to be and what shape it takes, so the first attempt is closer.

The three demo gifs in docs/ show a brief turning into a hype promo, into a clean product demo, and into a one-take product story, which is the fastest way to judge whether a format matches what you want before you run it.

sound-effects measured against the beat

The sound-effects skill is the one with the most specific technical claim in the table, and it is worth reading carefully.

It adds real sound effects timed to the beat and measured, so it does not sound like cheap beeps. Two things are bundled in that sentence. The first is the source recording: real sound effects rather than synthetic tones, and the licence section confirms that the repository ships an sfx directory under skills/sound-effects/sfx/ with files released under CC0 1.0, with the full licences in a LICENSES.md file inside that skill.

The second is the timing, which is described as measured against the beat rather than eyeballed. A sound effect that lands a few frames late against the music is the classic amateur tell, and the word measured suggests the skill instructs the agent to derive placement from the beat grid rather than guess it.

The demo gif shows a silent clip and then the same clip with sound effects added, which makes the change easy to evaluate on its own. The README also credits a sound-pass method by Vox, with full credits in each skill's README, which is worth reading since it tells you whose approach the skill encodes and under what terms it is reused.

The licences are layered, not just MIT

The repository README states the licence as MIT for the project itself, but the line then lists four other licences for the assets the skills bring in.

The Geist fonts are under the SIL Open Font License. Icon paths are adapted from Lucide under the ISC licence. The sound effects in skills/sound-effects/sfx/ are CC0 1.0, with details in that skill's LICENSES.md file. And the sound-pass method is credited to Vox, with the full credits in each skill's README rather than in the top-level file.

That layering matters for anyone shipping a video commercially. The MIT licence covers the skill instructions, which are text, but it says nothing about a font you render with or an audio file you drop onto a timeline. CC0 for the sound effects is as permissive as it gets, the Open Font License permits embedding fonts in rendered work, and the ISC terms on the Lucide derived icon paths are short and permissive. The point is not that any of these are troublesome, it is that a single MIT label on the repository root does not describe the whole asset set.

There is a small discrepancy worth flagging as well. The repository's licence field on GitHub reports a custom licence that GitHub cannot classify, and the root holds a LICENSE file, while the README says MIT. Read the LICENSE file to see which wording applies to the instructions themselves.

None of this is legal advice, but it is the part of the licence that a publishing team should check before a video goes out.

A text repository with demos, layered licences and no releases

The honest limitation of this repository is structural. A skill is a folder of instructions that an agent reads. It is not a program with a deterministic pipeline, it is not a plugin that runs without a model, and it is not a toolchain that guarantees the same output twice.

That has consequences. If you run the same skill twice on the same footage you may get two different edits, because the agent interprets the instructions each time. If the skill depends on software that has to be installed on your machine, the README for that skill has to say so, and the top-level page does not enumerate the dependencies. The repo layout shows only .gitignore, LICENSE, README.md, docs/ and skills/, which tells you the whole project is text, gifs and skill folders, with no code to run and no dependency manifest at the root.

The second limitation is that the top-level README is a table, not a manual. Each skill's README is the full guide, and its length and depth are unknown from the outside. Someone adopting this should expect to read six documents, one per skill, and to find that one of them is much thinner than the others.

There is also a commercial context next to the project. The README points at a paid community where the author teaches the full AI video editing process, which is a normal way to fund this kind of work but it also means the open repository is a subset of a larger method, and the split between what is free and what is taught elsewhere is worth checking before you build a pipeline on it.

The alternative to this repository is a conventional editing pipeline, where the decisions are encoded in a script or in a project file that a renderer executes.

The difference in approach is where the intent lives. In a scripted pipeline you write the cuts, the timings and the effects, and the tool executes them, so the same input produces the same output and a change is a diff you can review. With an agent skill, the intent is written as prose that the model interprets, so you get flexibility on unseen footage and you lose reproducibility and reviewability in the same step.

That trade-off decides the use case. For a series of product videos where every clip is different and you want the agent to adapt, the skill approach earns its place, because a script would need a human to rewrite it for each video anyway. For a repeatable format with a fixed template, for instance a hundred explainer videos from the same script, a scripted pipeline with fixed durations and beat-locked placements is more reliable and far cheaper, because you pay for the model once rather than per render.

The middle path is to use the skills for exploration and the scripted pipeline for production, taking the timings the agent proposes and baking them into a template. The skills are structured enough, with named formats and fixed lengths, to be useful in that role.

A text repository with demos and no releases

The repository is not archived, and the last push was on 2026-10-13, so the skills are being worked on. There are no GitHub releases, which is consistent with a repository of instructions that are consumed straight from the default branch main rather than as versioned artefacts.

That has a practical consequence for anyone automating the install. The npx skills add command pulls the current state of the repository, so a change to a skill's wording lands in your project the next time you refresh, with no version pin in the manifest to hold it back. For a team that has tuned a skill to their own footage and delivery specs, the safe move is to copy the folder into .claude/skills/ and commit it, which is the path the README already offers and which turns the skill into a file you control rather than one that changes under you.

The documentation structure is the same story. There is one README per skill with its own credits and licences, plus the docs/ directory holding the demo gifs, and the LICENSES.md file inside the sound-effects skill. Nothing here needs a build step, and nothing needs a runtime, which is exactly why the only release artifact is the text itself.

Editorial conclusion

motion-graphics fits a creator or small team that already runs Claude Code or Codex and wants repeatable video editing instructions, because each skill is a self-contained folder with its own README that an agent can read. It does not fit a production pipeline that needs reproducible renders, or a team that wants the editing decisions to live in a timeline file rather than in a model conversation. Before you adopt it, open the README of the individual skill you care about, since the top-level page only lists what each one is for, and check the extra licences for the fonts, icons and sound effects that the skill will pull into your edit.

Frequently asked questions

Official sources

1. Barty-Bart/motion-graphics on GitHub
2. Issues
3. README