LottieFiles/motion-design-skill: Motion Direction Instructions for Coding Agents
Universal motion design principles for AI agents — timing, easing, choreography, and Disney animation principles adapted for UI
At a glance
- What is it?
- An MIT-licensed prompt and reference pack that tells AI coding agents how to reason about timing, easing and choreography before they emit animation code. It is documentation, not a runtime, and its value depends entirely on how the host agent loads skill files.
- Who is it for?
- Adopt it if your team already uses a skills-aware agent and your recurring problem is agents emitting default ease-in-out transitions with no stated intent. Skip it if your animation work is hand-authored, or if you need a runtime library rather than written guidance.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 120 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
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 Gap This Fills: Agents That Animate Without Intent
Ask an AI coding agent to add an entrance animation and you tend to get something plausible and generic: a fade with a short translate, an ease-out curve, a duration picked from habit. The code runs. Nothing about it says why 200ms instead of 400ms, or why the card moves before the modal. The repository's stated aim is to fix that ordering of operations. It describes itself as "philosophy-first, implementation-agnostic," and the README frames the goal as teaching agents to choose timing, easing, choreography and emotional intent "before writing a single line of animation code." That is a claim about sequencing, not about output quality.
The audience is narrow and specific. This is for teams whose animation decisions are currently being made by a language model inside an editor, and who want those decisions constrained by a written standard. It is not for a designer hand-tuning keyframes in After Effects, and it is not for a developer who already has a motion spec. The README lists the activation contexts: UI animations such as buttons, cards, modals and page transitions, micro-interactions, loading and error states, scroll-triggered work, brand motion identity, and multi-element sequencing. If your work falls outside those categories, the skill has nothing to say to you.
What Actually Ships: A File Tree, Not a Library
There is no package to import and no runtime to install. What the repository contains is a directory of markdown files under skills/motion-design/. The README describes four groups. SKILL.md is the main instruction file, kept under 500 lines, and holds an 8-step checklist, motion personality archetypes, duration and easing tables, a property selection guide, common patterns and quality rules. The director/ directory holds eight files covering a three-pillars philosophy, a decision framework, Disney's twelve principles adapted for UI, four motion personality archetypes, emotion-to-motion mapping, choreography, narrative structure, and context adaptation for platform, accessibility and performance. The patterns/ directory holds four recipe files for entrance and exit, state feedback, ambient and continuous motion, and multi-element choreography. The reference/ directory holds four lookup files for timing and easing, property selection, a quality checklist and troubleshooting.
The architecture is therefore a retrieval problem rather than an execution problem. Nothing in the repository computes an easing curve or generates a keyframe. The agent reads prose and tables, then writes code in whatever system the project already uses. The README names CSS, Framer Motion, GSAP, Lottie and Spring as compatible targets, which is consistent with a document that never commits to an API surface. The practical consequence is that output quality tracks the host agent's ability to load and follow long-form instructions, not the skill's own correctness.
Installation and the Agent Compatibility Question
Installation is a single command, given verbatim in the README:
npx skills add LottieFiles/motion-design-skill
The README states this supports 40 or more agents, listing Claude Code, Cursor, Codex and GitHub Copilot among them, and points to skills.sh for the full set. There are no configuration keys documented in the supplied material, no environment variables, and no options flags. That is worth noting rather than glossing over: the entire configuration surface appears to be which agent you install into.
That makes the compatibility claim the load-bearing one, and the README does not break it down. It does not say whether every listed agent reads the director/, patterns/ and reference/ subdirectories or only SKILL.md. It does not describe how the subdirectory files are selected at runtime, or whether the agent decides relevance itself. If your agent only loads the top-level file, you get the checklist and the lookup tables and none of the philosophy material, which is most of the repository by file count. Verify this against your specific agent before assuming the full skill is in play.
The Three Pillars and the Decision Pipeline
The README names the organising concepts without defining them. director/core-philosophy.md is described as a deep dive into "the three pillars," and director/decision-framework.md as the "full decision pipeline." Neither file's contents are in the supplied material, so the actual content of the pillars and the ordering of the pipeline cannot be confirmed here. What can be confirmed is the shape of the argument: emotion and intent are resolved first, then choreography, then timing and easing, then property selection. The 8-step checklist in SKILL.md and the decision framework in director/ appear to be two views of the same sequence, one compressed for quick reference and one expanded.
The Disney material is the most concrete thing the README points at. Twelve principles originally written for hand-drawn character animation, adapted for interface work, is a real translation problem. Squash and stretch, anticipation and follow-through have obvious analogues in button presses and modal transitions; others translate less cleanly. The README asserts the adaptation exists but gives no example of how any single principle was rewritten for UI. Treat that file as the first thing to read before trusting the rest, because if the adaptation is loose, the vocabulary will sound authoritative without constraining anything.
Where This Breaks Down
The failure mode is instruction decay. A skill file competes with everything else in an agent's context: the codebase, the framework conventions, the user's own prompt, and whatever default the model reaches for under pressure. A 500-line main file plus sixteen supporting documents is a lot of material for a model to hold while writing a single transition. The README's own structure acknowledges this by keeping SKILL.md under 500 lines, which suggests the authors expect the main file to be what actually gets read.
A second limitation is the absence of verification. There is no test suite, no linter, no way to check whether generated animation conforms to the quality checklist in reference/quality-checklist.md. The checklist is prose, and prose checklists are advisory. An agent that ignores the timing tables produces code that looks identical to code that follows them until a human reads it.
Third, the skill is the wrong tool when the constraint is not judgement but capability. If your problem is that your animation library cannot express a spring, or that your build pipeline strips keyframes, no amount of written principle helps. It is also the wrong tool for accessibility compliance in the strict sense. director/context-adaptation.md is described as covering accessibility, but a document that advises an agent is not a substitute for testing against prefers-reduced-motion in a browser.
Compared With Writing Your Own Motion Guidelines
The obvious alternative is a house style guide: a markdown file in your repository listing your durations, your easing tokens and your stagger rules. The difference in approach is scope versus specificity. A house guide encodes your decisions and nothing else. It can say "modals use 240ms ease-out" and be exactly right. This skill does the opposite. It is implementation-agnostic by design, which means it cannot tell your agent that your design system uses a particular cubic-bezier. It gives the agent a reasoning process and expects the agent to arrive at a value.
That trade-off cuts both ways. A house guide drifts as your system changes and needs an owner. This skill is maintained upstream and covers ground a small team would not write: emotion mapping, narrative structure, Disney principles. But it will never know your tokens. The realistic setup is both, with the skill supplying the reasoning frame and a short project file pinning the actual numbers. The README does not describe any mechanism for overriding the skill's tables with project-specific values, so that combination is something you would assemble yourself.
Maintenance, Licence and What to Check First
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement and imposes no copyleft obligation on the animation code your agent produces. This is a description of the licence text, not legal advice; if the skill is redistributed inside a product, have counsel confirm the notice requirements.
The maintenance picture is thin. The supplied material shows no releases, and the last push was 2026-05-18. There is no changelog and no versioning scheme to pin against, which matters more here than for a library. A library upgrade is a version bump you can test. A skill upgrade silently changes the instructions your agent follows, and there is no test that will catch a behavioural shift. The README does not describe an update command, so the upgrade path is unclear.
What to verify first: read SKILL.md end to end and check whether the 8-step checklist matches how your team actually reasons about motion. Then confirm your agent loads the subdirectory files. Then check director/context-adaptation.md for whether the accessibility guidance names prefers-reduced-motion or stays abstract. Those three checks will tell you more about fit than the install command will.
Editorial conclusion
Adopt it if your team already uses a skills-aware agent and your recurring problem is agents emitting default ease-in-out transitions with no stated intent. Skip it if your animation work is hand-authored, or if you need a runtime library rather than written guidance. Before adopting, open SKILL.md and confirm its 8-step checklist matches your house style, then check whether your agent actually loads files from the director/, patterns/ and reference/ subdirectories rather than only the top-level skill file.
Community notes