emilkowalski/skills: design and animation rules for coding agents

The problem: agents pick the wrong ingredients

The README states the failure mode directly. Agents choose an `ease-in` easing for an enter animation when it should be `ease-out`, or pick a solid border instead of a semi-transparent shadow. Each choice is small. The README argues they compound until an interface is either good or not that great, and that knowing whether you made the right call on animation is hard in the first place.

The intended audience is designers and engineers building user interfaces, particularly those who already have an opinion about motion and want an agent to follow it. The author frames the skills as a byproduct of working at companies like Vercel and Linear, and says the repository exists to reach correct decisions faster. That framing matters: the files encode a point of view, so the value depends on whether you share it.

What actually ships: fourteen Markdown skill files

There is no package to import and no server to run. The repository is Markdown plus a `skills/` directory, and each skill is a `SKILL.md` file. The README lists fourteen of them, and the split is worth reading before installing anything.

`emil-design-eng` is the main skill and covers mostly animation plus some general design advice. `animate` builds an animation from scratch, choosing curve, duration and properties. `animate-expo` does the same job for React Native and Expo, covering gestures, sheets, haptics, screen transitions and keeping motion off the JS thread. `review-animations` applies the author's rules strictly to animations you already have. `improve-animations` audits a codebase and produces prioritized, self-contained plans for an agent to execute. `find-animation-opportunities` looks for places that would benefit from motion and says what not to animate. `animation-vocabulary` is about phrasing requests so a model understands them.

The remaining entries step outside motion. `apple-design` distills Apple's interface and fluid motion principles from WWDC talks for the web. `write-swift` covers value types, Swift 6 concurrency, generics, performance and Swift Testing. `pick-ui-library` constrains library choice to a set the author uses and trusts, with the stated goal of stopping an agent from hand-rolling a toast component or installing an abandoned package. `prototype` builds several versions of a described UI piece behind a switcher. `mobile-native` collects small web-on-phone fixes: sticky hover states, tap highlight flashes, the 100vh bug, inputs that zoom the page, laggy taps and safe areas. `ask-sonner` documents the author's own Sonner toast library, including setup, styling, recipes and common fixes.

Install and a first real use

The README gives a single install command. Run it from the root of the project whose agent you want to influence.

npx skills@latest add emilkowalski/skills

That pulls the skill set through the `skills` CLI and adds it to the current project. The README does not document where the files land on disk, so check your working tree after the command finishes rather than assuming a path.

From there, the practical first move is to point the agent at one skill instead of the whole set. `review-animations` is the narrowest useful entry because it reviews what you already have instead of generating something new, so you can judge the output against your own code.

ls skills/

The README's reference section links each skill by path, for example `skills/review-animations/SKILL.md`. Read that file before you let an agent act on it. The rules are the product, and they are short enough to skim.

If you want the audit workflow instead, `improve-animations` is described as producing prioritized, self-contained plans that any agent can execute. That phrasing is a hint about scope: it plans, it does not silently rewrite your codebase.

Where it breaks down

The README is candid about the biggest limitation, though probably not on purpose. It says the skills are a side-effect of domain expertise, that AI does not replace such expertise, and that you should learn to code, design or develop expertise in another field. Read that as a design constraint. If you cannot tell a good easing curve from a bad one, you cannot tell whether the skill applied it correctly, and the review step becomes a rubber stamp.

There is a second, quieter problem. `pick-ui-library` restricts choices to libraries the author uses and trusts. That is a real opinion, and it will conflict with your existing stack whenever your team has already standardized on something else. The skill is not neutral infrastructure; it carries preferences that may not fit your product.

Third, the repository ships no version tags and no releases. The install command uses `@latest`, so what you get next month may not be what you got today. There is nothing to pin against. For a set of files that shape how an agent writes production UI code, that is a meaningful gap, and the README does not address it.

How this differs from a component library

The obvious comparison is a component library such as Radix, shadcn/ui or Headless UI. The difference is what gets shipped. A component library gives you code: buttons, dialogs, toasts, with behavior and accessibility handled. You import it and it runs.

This repository gives you instructions. Nothing is imported, nothing runs, and there is no runtime dependency in your bundle. The output is whatever your agent writes after reading the files, which means the same skill set can produce different code in different projects. That is the trade-off. You get adaptation to your existing codebase instead of a fixed component API, and in exchange you get no guarantees, no test suite and no changelog to diff against.

The two are not mutually exclusive. `pick-ui-library` exists precisely because the author expects you to use libraries and wants the agent to choose sensibly among them rather than hand-rolling a toast.

Maintenance, licence and upgrade cost

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement and is the usual choice for a repository of this kind. It is not legal advice; check the LICENSE file and your own obligations.

The repository is not archived, and the README does not state a release cadence. There are no releases to inspect, so you cannot reason about upgrade cost the way you would with a versioned dependency. There is no changelog to read before updating, and `npx skills@latest add emilkowalski/skills` will always fetch the current state of the default branch.

Upgrade cost is therefore mostly review time. Re-read the `SKILL.md` files you rely on after pulling, and check whether the rules still match your product. The README points to a newsletter at aiforui.dev for staying up to date, which suggests the author intends to keep adding skills. That is a signal, not a guarantee.

Editorial conclusion

Adopt it if you already ship interfaces and want an agent to stop reaching for ease-in on enter animations or a solid border where a semi-transparent shadow belongs. Skip it if you have no design opinion of your own, because the README is explicit that the skills are a side-effect of domain expertise rather than a replacement for it. Before trusting a run, open skills/emil-design-eng/SKILL.md and check whether its rules match your product, since the repository ships no tests and no version tags to pin.

Frequently asked questions

Official sources

1. emilkowalski/skills on GitHub
2. Issues
3. License: MIT
4. Project website
5. README