Collection review — 01 / Reviewed 8 November 2026
Skills for Designers and Engineers
Seventeen Markdown files that give an AI agent a design engineer's judgement about motion — and, more usefully, the authority to tell you no.
npx skills@latest add emilkowalski/skills
- Skills
- 17
- Format
- Markdown + SKILL.md
- License
- MIT
- Stars
- 54,148
- Installs
- 3.2M on skills.sh
- Last push
- 4 Nov 2026
- Assumes
- CSS · React · Expo · SwiftUI
- Reviewed
- 8 Nov 2026
The verdict
The best-designed skill collection I have read: opinionated, specific, and willing to produce nothing rather than motion that has not earned its place.
Install it if your agent writes front-end UI. If you work in Vue, Flutter or native Android, most of the specifics will not transfer — the collection is honest about its edges by simply not covering them.
What it is
This is not a library and not a framework. It is 17 folders of Markdown, one SKILL.md each, plus nine reference files the agent is told to load only when it needs them. There is no code in the repository at all — roughly 51,000 words of instruction and not one line to compile.
A skill is loaded by name and description when a task matches, and then the agent reads the instructions. That makes this a prompt library, but a very particular one: instead of describing a topic, each file makes decisions — durations, curves, property lists, thresholds, and an explicit list of things never to ship.
The premise comes straight from the README: agents do not have great taste. They pick ease-in for an entrance because it is common in the training data, a solid border where a translucent shadow belongs, a scale(0) pop because it is easy. Each mistake is small; together they make an interface feel untrustworthy. The skills are the corrections written down.
Why it earns a place
Plenty of prompt collections are summaries of public articles. This one is traceable to work: the rules match interfaces shipped at Vercel and Linear, and the author built Sonner and Vaul — the toast and drawer libraries a lot of React apps already run. The bookkeeping shows it. Exact cubic-bezier values, spring parameters in Apple's designer format, and a frequency threshold that decides whether a control animates at all.
The second reason is restraint. Three of the most useful files exist to take things away: find-animation-opportunities caps itself at five to seven suggestions for an entire app and must list the candidates it rejected; remove-animations starts from delete and walks back; review-animations can block a change. The collection would rather ship a static interface than a busy one. That bias is rare, and it is correct.
There is also a structural detail worth noticing: the skills route to each other. Descriptions end with 'for critiquing existing motion use review-animations'. The set behaves like a toolbox with labels, not seventeen prompts that happen to share a repository.
The 17 skills, grouped by job
The set is a routed toolbox, not seventeen unrelated prompts: the files reference each other by name, share one table of curves and durations, and treat review-animations as the final gate. Here they are in the order I would actually use them.
Decide what should move
Three files settle whether motion should exist before any code is written. Start here; the construction skills assume you have.
-
emil-design-eng start here
FoundationThe hub. A long, opinionated set of rules for motion and interface detail: a four-question gate before anything animates, named easing curves, press and gesture behaviour, clip-path techniques, and a mandatory Before/After review format.
Reach for it when you want one file that sets the bar — every other motion skill here routes back to it.
-
find-animation-opportunities
DecideAudits an interface for places that would genuinely benefit from motion, then throws most of them away. Output is capped at five to seven suggestions for an entire app, and every rejected candidate is listed with the question that killed it.
Reach for it when a page feels inert and you want to know whether that is a problem — before adding anything.
-
remove-animations
DecideThe subtraction pass. A decision tree for deleting motion — keyboard-triggered, a hundred times a day, decoration on functional data — plus the ways removal breaks things: hidden opacity start states, exit-completion waits, focus moved in a callback.
Reach for it when an interface feels busy, or before a redesign inherits years of transitions.
Build it
Construction skills. Each one is allowed to talk you out of the work, and each one ends in code rather than a menu of options.
-
animate
BuildConstruction, from the gate to the code. Seven ordered steps, a tool ladder that starts at a plain CSS transition, tables for curve and duration, and a 13-recipe reference covering press, dropdown, modal, drawer, toast, stagger and drag-to-dismiss.
Reach for it when one element should move and you want the agent to make the call instead of offering a menu.
-
animate-expo
BuildThe React Native and Expo version of animate, rewritten for different physics: no hover, two runtimes, a finger on the element. Reanimated worklets, Apple-style spring parameters, haptics rules, 120fps frame budgets and the setup traps that stop gestures working.
Reach for it when the target is a phone app, not a browser.
-
choreograph
BuildThe coordination layer: what leads, what supports, what overlaps, what stays still. Cast roles first, then choose one of four relationships per pair, with budgets by context and an explicit ban on uniform stagger.
Reach for it once more than one thing moves together — a panel and its contents, a list and its empty state.
Review, audit, repair
The part most collections skip: what to do when the motion already exists, is inconsistent, or drops frames.
-
review-animations
ReviewA merge gate for motion. Ten non-negotiable standards, findings with file and line, and an explicit Block or Approve at the end. It refuses to trigger itself, so the agent only reviews when you ask.
Reach for it when a change touches animation and you want a verdict, not a compliment.
-
improve-animations
AuditA whole-codebase audit that writes plans, not patches. It maps the stack and the existing motion, ranks findings by leverage, then writes self-contained plans specific enough for an executor with zero context and zero taste.
Reach for it on a legacy app where motion is inconsistent and you want the work split into tickets.
-
animation-performance
DiagnoseDropped frames, diagnosed in order of likelihood. Frame budgets at 60 and 120Hz, the composite/paint/layout pipeline, the two traps that still use transform — an inherited CSS variable on a parent, an animated blur — and the evidence rule: from code, or needs a device recording.
Reach for it when the animation is correct but feels heavy, especially on a mid-range phone.
Reference and taste
Lookup files. Useful in the middle of a task, not at the start of one.
-
apple-design
ReferenceApple's fluid-interface principles translated to the web: momentum projection instead of a parabola, rubber-banding, velocity handoff, materials and vibrancy, and the two spring parameters designers actually think in. Largely distilled from WWDC 2018.
Reach for it when a gesture should feel physical rather than merely animated.
-
animation-vocabulary
ReferenceA reverse-lookup glossary: 91 terms across 12 groups for the thing you can describe but not name. Say 'the popover should grow out of the button' and it returns origin-aware animation, plus one or two alternates with the difference between them.
Reach for it when a prompt keeps returning the wrong motion because you are describing a feeling instead of a technique.
-
pick-ui-library
ReferenceNineteen libraries in five tables, matched to tasks rather than names: base-ui, cmdk, Sonner, NumberFlow, torph, dnd-kit, Virtuoso, zustand. It reads package.json first and recommends one, not a menu. Deliberately not auto-triggered.
Reach for it when the agent is about to hand-roll a toast, a dropdown, or a thousand-row list.
Beyond motion
Five skills about other things — the reason the collection is broader than its title suggests.
-
mobile-native
PolishEleven fixes that separate a website from an app on a phone: sticky tap highlights, the 100vh bug, inputs that zoom the page, the 300ms tap delay, safe areas, per-scheme theme colour. Pure CSS and meta tags, no library, and a never-ship list that includes disabling zoom.
Reach for it the week a web app ships to phones, before anyone files 'feels laggy'.
-
break-ui
QAAdversarial QA with worst-case data behind a dev-only toggle: a 60-character email, a one-letter first name, 1,284 members. It maps every rendered value to its source and limit, then reports Broken, Ugly or Fragile with a symptom-to-fix table.
Reach for it on any component that renders user data and has only ever been tested with 'Jane Doe'.
-
prototype
ExploreBuilds three to five genuinely different versions of a UI piece and puts them behind a picker, one at a time at full size. Variants must diverge on a named axis; three tints of one idea is a failure. The human picks, and the prototype surface is deleted afterwards.
Reach for it when the direction is undecided and a static mockup would settle nothing.
-
write-swift
LanguageHow to write modern Swift, and the only file here with nothing to do with motion. Value types before classes, Swift 6 concurrency doctrine including @concurrent and actor reentrancy, SwiftUI closure rules, and Swift Testing as the default. At 42 KB it is the longest skill in the set.
Reach for it when the agent writes Swift and keeps reaching for pre-6 patterns.
-
ask-sonner
LibraryThe guide to Sonner, the toast library the author built: setup, which call to use, update-by-id recipes, the four-rung styling ladder, and a troubleshooting table for the bugs people actually hit — duplicate toasts under StrictMode, theme not following the OS, toasts trapped behind modals.
Reach for it if Sonner is in package.json. Worth saying plainly: the author is recommending his own library. The advice is good; the bias is real.
Where it falls short
- Mostly motion. Eleven of the seventeen skills are about animation or design motion. If you came for general front-end doctrine, you get four or five files and a language guide.
- A React-and-Swift stack. The web skills assume CSS, React and usually Motion; the mobile ones assume Expo or SwiftUI. Vue, Svelte, Solid, Flutter and native Android are not covered, and the specific values do not transfer.
- House rules, not physics. Ease-in is banned; UI motion must stay under 300ms; stagger on high-frequency UI is forbidden. Coherent and defensible, but it is one excellent engineer's opinion, and it will occasionally disagree with your brand.
- Version-sensitive. Motion 14.2, Reanimated 4, Expo SDK defaults, Swift 6.3 against an unreleased 6.4 — the files name versions and will drift. Installing pulls main; there is no changelog and no tagged release.
- Prose, not tests. Nothing here is benchmarked. The claims are craft assertions — 180ms feels more responsive than 400ms — not measurements. The value depends on the host model actually following a long instruction file.
- The tool list is personal. pick-ui-library is one engineer's trusted stack, and several picks are his own libraries. Treat it as a strong default, not a survey of the field.
None of this is disqualifying — it is what the thing is. A specialist's notebook is more useful than a generalist's summary, provided you know which specialist you are hiring.
Who it is for
Useful if
- Design engineers shipping React or Next.js UI who want an agent to stop guessing at motion.
- Teams doing an animation audit or a 'why does this feel slow' pass — the audit and subtraction skills are the strongest artifacts in the set.
- Expo, React Native and SwiftUI developers who want the same craft bar applied natively.
- Anyone who wants their agent to push back. These files say no, and explain why.
Skip it if
- You work in Vue, Svelte, Flutter, Kotlin/Compose or native Android — the specifics do not carry over.
- You want menus of options and generated boilerplate rather than one defended decision.
- You need measured performance budgets or accessibility certification. This is craft advice, not compliance.
How to use it well
- Install per project, not globally. Run the CLI from the repository the agent works in. Skills that live next to the code get read at the right moment; skills buried in a global prompt get loaded for everything and trusted for nothing.
- Ask whether it should move before asking how. Start with animate's first gate. A surprising share of requests should end with zero lines of code, and this collection treats that as the correct answer, not a failure.
- Use the review gate on real diffs. review-animations is designed to block. Run it on any pull request that touches motion and let it be the last word rather than one opinion among many.
- Do subtraction first on old code. On a mature codebase, remove-animations and improve-animations return more than anything additive. The audit skills write plans a cheaper model can execute — that split is deliberate.
- Keep the platform forks straight. animate is for the web; animate-expo is for React Native. They share a philosophy, not code. Installing both is fine. Invoking the wrong one produces confident nonsense.
Sources and further reading
- emilkowalski/skills on GitHub The source. MIT licensed, 17 skills, no code.
- emilkowalski/skills on skills.sh Install counts quoted above — a snapshot from 8 Nov 2026.
- The Agent Skills specification What a SKILL.md is, and how progressive disclosure works.
- emilkowal.ski The author's essays; several skills cite them directly.
- Animations on the Web The author's animation course, referenced by the repo.
- Sonner The toast library documented by ask-sonner; the author wrote it.
- Vaul The drawer library by the same author.