diffusionstudio/lottie: generating Lottie JSON from a coding agent prompt

What text-to-lottie generates, and for whom

The project targets Lottie JSON, the JSON-based animation format that players such as lottie-web, Lottie for iOS and Android, and Flutter's lottie package render at runtime. Writing that JSON by hand is unpleasant: keyframes, easing handles and shape transforms are verbose and unforgiving. Text-to-lottie's pitch is that a coding agent writes it for you from a prompt, and the repository describes the result as "production ready Lottie animations".

The intended user is someone who already works inside a coding agent. The README's Quick Start assumes Claude Code, Codex or another agent that supports skills, and the example prompt asks for an SVG path to be revealed along its natural direction with an Apple-style gradient, ease-in-out timing and a transparent background. This is not a tool for a motion designer who wants a timeline editor. It is for engineers and technical designers who would rather describe motion in text and then read the JSON.

How the skill, the player and the scene files fit together

Two pieces do the work. The first is a skill installed into the agent. The second is a Vite application that the README calls "the included player", which the agent sets up as a workspace.

Animations are organised as scenes inside projects. The README states that scenes load automatically from public/projects/<project>/<scene>/lottie.json and live-update in the player as the agent edits them. That path is the contract between the two halves: the agent writes JSON into a directory under public/, and the player watches it. The practical consequence is that you can scrub and inspect a generated animation while the agent is still iterating, instead of exporting and re-importing between rounds.

The stack is TypeScript with SolidJS, Vite and Tailwind, and canvaskit-wasm is a runtime dependency, which the postinstall script copies into place. That means the preview path is a browser canvas renderer, not a native Lottie runtime, so what you see in the player and what an iOS device renders can differ. The JSON is the shared artifact; the renderers are not identical.

Installing the skill and generating a first animation

The README gives a single install command. Run it from the project where you want the skill available, and the skills CLI should register text-to-lottie with your agent.

npx skills add diffusionstudio/lottie

After that, the agent sets up the workspace and the player. If you want to run the player yourself, package.json defines the usual Vite scripts, so bun run dev starts the development server and bun run build runs tsc -b followed by vite build.

bun install
bun run dev

The postinstall step copies canvaskit into the public assets, so skipping the install and starting the dev server directly is likely to leave the renderer without its wasm payload. Once the player is up, prompt the agent with the skill name and a concrete asset. The README's own example is a good template:

Create a Lottie animation from the SVG path in <url>. Reveal the path with an
animation that follows the natural path direction. Use ease-in-out timing, a
transparent background, and preserve the original SVG geometry.

The agent writes the scene to public/projects/<project>/<scene>/lottie.json, and the player should pick it up without a manual reload.

The prompt guide is the real documentation

Five numbered habits in the README matter more than any configuration option. Ground the model with SVGs, real-world data or screenshots, because the README says results are significantly better when the animation is based on concrete assets. Use motion design terminology such as ease-in, ease-out and ease-in-out. Think like a camera operator and ask for pushes, pans and zooms. Request controls explicitly, because the README states that outputs usually expose only a background color control by default. Specify FPS and total frame count when timing matters.

That last point is the sharpest constraint in the whole project. If you want a colour, speed or size exposed to a downstream integrator, you have to ask for it in the prompt; it will not appear on its own. This makes prompt reuse valuable and prompt improvisation costly. Treat the prompt as a specification, not a wish.

Where text-to-lottie breaks down

The workflow assumes an agent that supports skills. If your agent does not, the install command has nothing to attach to, and the repository does not document a fallback path for driving the generator without one.

The second limitation is determinism. The README's guidance about grounding the model exists because ungrounded prompts produce weaker output; nothing in the repository describes a seed, a locked model version or a reproducible build of an animation. Two runs of the same prompt are not promised to produce the same JSON, and the README does not document rollback or versioning of generated scenes. If your pipeline needs byte-identical assets across builds, this is the wrong tool.

Third, the preview renderer is canvaskit-wasm in a browser. The README's own integration examples span lottie-web, React Native Skia, iOS Swift, Android Kotlin and Flutter, and those runtimes do not implement every Lottie feature identically. The README does not describe a validation step that checks a generated file against each target runtime, so cross-platform verification is your job.

Text-to-lottie against LottieFiles and hand-authored JSON

The obvious alternative is LottieFiles, whose editor and marketplace assume a human at a timeline: you drag keyframes, preview, and export. Text-to-lottie inverts that. There is no timeline UI in the repository listing; the interface is a prompt and a player that watches a file path. The trade-off is control. A timeline gives you precision on a specific keyframe; a prompt gives you speed on a whole animation and lets you regenerate it, but you steer by describing intent and re-reading JSON.

The second alternative is writing the JSON yourself or exporting it from After Effects. That gives you exact geometry and full use of After Effects tooling, at the cost of the manual work the agent is meant to remove. The README positions the two as complementary rather than exclusive: generated animations can be imported into After Effects for further refinement.

Licence, dependencies and upkeep

The repository is MIT licensed and package.json declares "license": "MIT", so you can use generated output and the framework in commercial products subject to the licence text. That is a statement about the repository, not legal advice; the Lottie format itself and the runtimes you render into carry their own terms.

On maintenance, the last push was on 2026-07-25, and the most recent release listed is v1.0.0 from 2026-06-15. The repository is not archived. The dependency surface is broad for a tool of this size: SolidJS, Vite 7, Tailwind 4, canvaskit-wasm, fflate and a shadcn dependency, all pinned with caret ranges. Upgrades will mostly be Vite, Tailwind and canvaskit moves, and canvaskit-wasm is the one to watch because the postinstall script copies it into place. There is also a check:text-slots script that runs a Node test over text-slot Unicode handling, which suggests text rendering in generated animations has had edge cases worth testing.

Editorial conclusion

Adopt it if you already drive a coding agent and want Lottie JSON you can inspect frame by frame in a local player, and if you can supply an SVG, screenshot or dataset rather than a description alone. Do not adopt it if you need a hosted design tool with a graphical timeline, or if you expect the agent to guess your brand assets. Before committing, verify the skill actually registers under skills/ in your agent, confirm the player picks up public/projects/<project>/<scene>/lottie.json on your machine, and check that the generated JSON opens in After Effects if that is your downstream step.

Frequently asked questions

Official sources

1. diffusionstudio/lottie on GitHub
2. License: MIT
3. Project website
4. README
5. Releases