emilkowalski/skills: Agent Instructions for Animation and Interface Detail
Skills for Designers and Engineers.
At a glance
- What is it?
- A set of Markdown skill files that tell coding agents how to pick easings, durations and UI components instead of guessing. The repository is documentation, not a runtime, and its value sits entirely in the quality of the rules it encodes.
- Who is it for?
- Adopt this if your team already runs a coding agent and keeps seeing the same animation mistakes: wrong easing direction on enter animations, solid borders where a semi-transparent shadow belongs, or a hand-rolled toast. Skip it if your interface work is mostly backend, data or infrastructure, since most of the twelve skills are motion and UI specific.
- 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 received new commits within the last day.
- What is it written in?
- Mainly Markdown, 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 gap these skills fill: agents with no design judgement
The README is direct about the problem. Agents, it says, do not have great taste. The example given is concrete: an agent choosing ease-in for an enter animation when the correct choice is ease-out, or picking a solid border instead of a semi-transparent shadow. Neither mistake breaks a build. Both are the kind of detail that separates an interface that feels considered from one that does not, and neither shows up in a type checker or a linter.
The author states the skills are a side effect of domain expertise built while working at companies including Vercel and Linear. That framing matters for who this is for. This is not a general purpose agent toolkit. It is a written-down version of one designer-engineer's opinions about motion, aimed at people who already use an agent to write frontend code and want the output to stop looking generic. If you do not use an agent for UI work, there is little here to run.
What is actually in the repository: twelve Markdown skill files
The primary language is Markdown, and that is the whole architecture. Each skill is a directory under skills/ containing a SKILL.md file. The reference list names twelve: emil-design-eng, animate, animate-expo, review-animations, improve-animations, find-animation-opportunities, animation-vocabulary, apple-design, write-swift, pick-ui-library, prototype and ask-sonner.
The spread is wider than the title suggests. write-swift covers value types, Swift 6 concurrency, generics, performance and Swift Testing. ask-sonner is documentation for Sonner, the author's toast library. apple-design is described as Apple's interface and motion principles distilled from WWDC design talks and translated for the web. animate-expo targets React Native and Expo, covering gestures, sheets, haptics, screen transitions and keeping motion off the JS thread.
The skills also differ in posture. Some generate work (animate builds an animation from scratch, prototype builds several versions of a UI piece with a switcher). Others audit existing code (review-animations applies the author's rules strictly, improve-animations produces prioritized self-contained plans, find-animation-opportunities searches for places worth animating and also says what not to animate). That split between creating and reviewing is the most useful structural decision in the set.
How the skills reach your agent
Installation is a single command from the README:
npx skills@latest add emilkowalski/skills
There is no build step, no configuration file documented in the README, and no runtime dependency. The repository is content. Whatever the skills CLI does with the files (copying them into an agent's skill directory, presumably) is not described in the README, so treat the install command as the documented entry point and nothing more.
The README also points to a newsletter at animations.dev/skills for staying up to date. That is worth noting as a maintenance signal: the project's update channel is a mailing list plus commits to the default branch, not releases. No releases were retrieved for this repository, which means there is no version number to pin and no changelog to diff against when the skills change.
The maintenance model is the weak point
Because every skill is prose, every improvement is an edit to instructions an agent will follow. There is no test that fails when a rule is wrong, no fixture that catches a regression in advice, and no release artifact that freezes behaviour. If the author revises how enter animations should be eased, your agent's behaviour changes on the next pull with no diff signal beyond the file content itself.
That is a real cost for teams. A dependency you can pin and audit at the version level behaves predictably. A skill file you copy into an agent's context behaves as well as the last commit. The practical mitigation is to vendor the SKILL.md files into your own repository, so upgrades are a deliberate diff you review rather than an implicit change. The README does not suggest this, and it is not a criticism of the author's intent, just the consequence of shipping guidance as text.
The licence is MIT, which permits use, modification and redistribution provided the copyright notice and permission notice are preserved. That is permissive enough for vendoring into a private repository. This is a description of the licence terms, not legal advice; check the LICENSE file and your own counsel if the distinction matters to you.
Where it will not help, and what to use instead
If your problem is enforcing design decisions mechanically rather than advising an agent, this is the wrong shape of tool. A design system with tokens and components, or a linting setup such as stylelint with rules for animation properties, constrains output by making the wrong thing fail. The skills here constrain output by making the wrong thing less likely. That is a weaker guarantee, and it degrades whenever the agent drifts from the instructions or the context window drops the skill.
The same applies to the write-swift skill. If you need Swift correctness enforced, the compiler and Swift Testing are the enforcement layer; a Markdown skill is a nudge about style and concurrency idioms. And if you do not run an agent at all, the entire repository reduces to a set of design essays you could read directly at the author's site, which the README links to anyway.
A concrete test before you commit
The cheapest way to judge this repository is to read two files and disagree with them. Open skills/emil-design-eng/SKILL.md and skills/animate/SKILL.md. If the easing and duration rules match what your team already believes, the skills will reinforce existing practice and the install is low risk. If you find rules you think are wrong, you have learned that adopting the set means adopting opinions you will have to override in review, which is a worse position than not installing it.
The second test is scoped to your codebase. Run the audit-oriented skill (improve-animations) against a small area first, since the README describes its output as prioritized, self-contained plans any agent can execute. If the plans it produces are specific to your components and reference real files, the skill is doing work. If they read as generic animation advice, the rules are too abstract to be useful in your code and you should say so before rolling it out further.
Who this is for
This fits a small frontend team already using a coding agent on interface work, where the recurring complaint is that generated components feel slightly off in ways nobody can name. The animation-vocabulary and pick-ui-library skills address that directly: one gives you the words to ask for a specific motion, the other steers the agent toward libraries the author uses and trusts instead of hand-rolling a toast or installing an abandoned package.
It fits less well for teams with a mature design system, because the skills will frequently conflict with decisions already made and codified. It fits poorly for anyone without an agent in the loop, and for backend or infrastructure work where write-swift and ask-sonner are the only remotely relevant entries. The repository is MIT licensed, small, and entirely text, so the cost of trying it is an afternoon of reading. The cost of depending on it without reading is an agent that follows rules you never agreed to.
Editorial conclusion
Adopt this if your team already runs a coding agent and keeps seeing the same animation mistakes: wrong easing direction on enter animations, solid borders where a semi-transparent shadow belongs, or a hand-rolled toast. Skip it if your interface work is mostly backend, data or infrastructure, since most of the twelve skills are motion and UI specific. Before trusting it, open skills/emil-design-eng/SKILL.md and skills/animate/SKILL.md and read the actual rules, because the repository ships prose and no test suite, no versioned releases and no changelog, so the only thing you can audit is the text itself.
Community notes