vibe-motion/skills: a skill pack for agent-generated motion design
agent skills for vibe motion
At a glance
- What is it?
- The repository collects roughly fifteen agent skills that turn a prompt into a Remotion, Three.js or p5.js animation, and installs them with a single npx command. The value is in the packaging, not the runtime, and several skills are thin wrappers around external projects the agent has to clone first.
- Who is it for?
- Adopt this if you already work inside an agent CLI such as Claude Code and want canned motion outputs (ruler progress bars, vinyl players, candlestick charts, Chladni particles) without writing the Remotion or Three.js scaffolding yourself.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is scaffolding, not animation
Writing a Remotion composition from scratch is mostly boilerplate: register the root, set the frame rate, wire the composition into the Studio, then draw. The same is true for a Three.js scene that only needs to render a rotating globe or a boids school. The repository targets that gap. Each skill is a packaged instruction set that tells an agent how to produce one specific motion artifact, so the user describes the effect in natural language and the agent writes the project files. The README frames the pack around trigger keywords, for example the ruler-progress-render skill lists the trigger phrase for a ruler progress animation and notes that the text and progress value are configurable. That is the design centre: a narrow, named output plus configurable parameters, rather than a general animation library. The intended user is someone already driving an agent CLI, not someone looking for a runtime dependency to import.
Installation goes through an interactive npx script
The README gives one command: npx skills add vibe-motion/skills. It is explicit that this is interactive. The user selects skills with the space bar, and the README recommends selecting all of them, then choosing the target agent, for example Claude Code, because different agents store skills in different paths. That last point is the first real constraint. The pack does not install into one canonical location. The path depends on which agent you picked, so the same repository produces different on-disk layouts on different machines. There is no configuration file documented in the README, no environment variable, and no non-interactive flag. If you want to script the install across a team, the material does not show how. The README also does not state a package version to pin, and no releases were retrieved for the repository, so there is no tagged version to reference either.
Three kinds of skill sit in the same folder
The skills are not uniform. The first kind generates output directly: ruler-progress-render, claude-typer, procedural-fish-render, light-spotlight-render, remotion-candlestick, remotion-3d-ticker, remotion-vinyl-player and printed-curtain-render each describe a self-contained effect, and several list their configurable parameters in the README, such as the spotlight skill's text, swing amplitude, lamp scale, glow and background colour, or the printed curtain's live physics panel. The second kind is a wrapper around an external repository. fisheye-motion instructs the agent to clone the vibe-motion/fisheye-motion project and change parameters before rendering. threejs-earth-render clones or updates vibe-motion/threejs-earth and renders through Puppeteer. 3d-chladni-render clones or updates nolangz/3D-Chladni and uses that project's deterministic exporter. wechat-2d-render clones or updates sxhzju/wechat-2d. The third kind is advisory: disney-animation-rule-skill applies the twelve Disney animation principles to code-driven animation and is meant for reviewing or debugging motion that feels stiff or mechanical. Those three categories have very different failure modes, and the README does not separate them.
The wrapper skills inherit someone else's repository
This is the part worth reading carefully before adopting. Four skills do not ship the animation engine. They ship instructions to clone a separate project and drive it. That means the install command is not the end of the setup: the first run of fisheye-motion, threejs-earth-render, 3d-chladni-render or wechat-2d-render needs network access and a working clone of a repository that lives outside this one. If the upstream project moves, renames a script or changes its export flags, the skill's instructions can go stale without anything in this repository changing. The README says the skills clone or update the target, which suggests the agent is expected to pull the latest state rather than a pinned commit, so reproducibility depends on upstream stability. The 3d-chladni-render skill is the clearest example: it advertises a deterministic exporter and reproducible seeds, but the determinism is a property of the cloned project, not of this skill pack.
Licence and asset terms are the weak spot
The repository's licence field is unknown in the metadata supplied here, and the README does not state a licence for the pack itself. That is a gap you have to close yourself before using the output commercially. Worse, the README carries attribution notices that apply to specific assets and engines. The printed curtain skill notes that its rope engine is adapted from Jason Labbe's Dynamic ropes 2 under CC BY-SA 4.0. The Chladni skill credits preview media to Lykno under CC BY-NC 4.0, and the NC clause rules out commercial use of that material. The fisheye, earth and wechat skills pull in separate repositories whose terms are not described in this README at all. None of this is legal advice, and none of it is a reason to avoid the pack, but it does mean the licence position is per-skill and partly per-asset. A team that needs a clean provenance chain will have to check each skill it uses, and the pack does not make that easy.
Where it breaks, and what to use instead
The clearest failure mode is the wrong-agent case. The README states that skill storage paths differ per agent, and the install script asks you to pick one. If your team uses an agent the installer does not list, or if you want the same skill available across two agents, the material gives no path for that. The second failure mode is the non-interactive install, described above. The third is the wrapper skills needing a clone. If any of those three apply, a plain Remotion project with your own compositions is the better fit, and the difference is structural rather than cosmetic. Remotion gives you a versioned npm dependency, a documented API surface, and a build you can pin in package.json. This pack gives you prompt-triggered generators whose behaviour lives in files the agent reads, with no version number attached. The trade is speed of first output against reproducibility. For a one-off launch video or a demo GIF, the pack wins on time. For a component that ships inside a product and has to render the same way in eighteen months, Remotion on its own is the safer base, and you can still borrow the skill's parameter ideas by reading the skill file.
Maintenance cost sits with you, not with the pack
There are no retrieved releases, so there is nothing to pin and nothing to diff against when behaviour changes. The last push recorded is 2026-09-04, which tells you the project is active but not how it versions. The contribution guide asks that every GIF be compressed below 1 MB (1,000,000 bytes) and preferably below 250 KB (250,000 bytes) by lowering preview resolution, frame rate and palette size, while keeping full duration, looping and key text legible. That is a real constraint on anyone adding a skill, and it hints at how the repository is maintained: previews are checked in as assets, so the repository grows with every skill. For a consumer of the pack, the practical maintenance work is re-reading the wrapper skills after any upstream change, and re-checking the licence notices when you swap assets. Budget for that, because the pack will not do it for you.
Editorial conclusion
Adopt this if you already work inside an agent CLI such as Claude Code and want canned motion outputs (ruler progress bars, vinyl players, candlestick charts, Chladni particles) without writing the Remotion or Three.js scaffolding yourself. Do not adopt it if you need a supported library with a versioned API, a licence you can read off the repository page, or a build that works without network access, because several skills clone third-party repositories at run time and the licence field is not populated. Before installing, run npx skills add vibe-motion/skills and read the per-skill files for the ones you actually want, then check the licence and preview-asset terms of any external project a chosen skill pulls in, such as fisheye-motion, threejs-earth or 3D-Chladni.
Community notes