Design judgment practice and rule sources
The emilkowalski/skills repository description is one sentence: "Skills for Design Engineers." Emil Kowalski states in the README that these skills draw on his experience at Vercel, Linear, and other companies. AI-generated interfaces can run and animate, but incorrect easing curves, shadows, and durations accumulate, determining whether an interface is "stunning" or "just ordinary"; SKILL.md states explicitly that agents don't have great taste.
The philosophy has three principles: taste develops through practice, by studying excellent work, reverse-engineering interactions, and repeated practice rather than personal preference; details have cumulative effects, as subtle adjustments most users do not notice combine to affect interface quality; aesthetics create differentiation, with polished motion among the few remaining differentiators in a software market where features converge.
The three skills have clear roles: emil-design-eng is the main design philosophy and judgment framework, review-animations strictly reviews animation code, and animation-vocabulary is a reverse-lookup vocabulary that converts vague descriptions into precise terms.
Judgment framework
Precise vocabulary
Strict review
All those unseen details combine to produce something that's just stunning, like a thousand barely audible voices all singing in tune.
npx installation and three skill triggers
Install through the official skills CLI without manually cloning or copying folders. Run this at the project root:
npx skills@latest add emilkowalski/skillsThe command installs emil-design-eng, review-animations, and animation-vocabulary together. The first two (the philosophy framework and vocabulary) load automatically in suitable contexts. The review-animations frontmatter explicitly sets disable-model-invocation: true, so review does not trigger automatically and must be invoked explicitly.
Design philosophy, vocabulary, and animation review
The three skills have distinct, nonoverlapping roles. emil-design-eng provides the judgment framework and normally loads automatically; animation-vocabulary converts vague descriptions into precise terms through reverse lookup. review-animations is the strict review skill: its disable-model-invocation: true frontmatter prevents default activation, and it intervenes only when animation review is explicitly requested.
Framework · 01
emil-design-eng
Design philosophy
A complete judgment framework for UI refinement, component design, and animation decisions. Covers frequency rules, easing selection, duration standards, GPU performance, and accessibility.
Vocabulary · 02
animation-vocabulary
Reverse-lookup vocabulary
Converts descriptions such as 'the effect that bounces when opening' into precise terms such as 'Pop in,' helping you communicate accurately with designers or AI.
Review · 03
review-animations
Animation review
Checks animation code against ten mandatory standards. Flags by default; approval must be earned. disable-model-invocation: true requires explicit invocation.
Core duration and easing standards (emil-design-eng)
These figures come directly from SKILL.md and are among the judgment framework's most frequently cited concrete rules.
| Element | Recommended duration | Recommended easing |
|---|---|---|
| Button press | 100–160ms | ease for hover / color changes |
| Tooltip, popover | 125–200ms | ease-out for entry |
| Dropdown, select | 150–250ms | ease-in-out for movement within the screen |
| Modal, drawer | 200–500ms | linear for continuous movement |
Animation review standards and approval conditions
The review-animations frontmatter says "Default to flagging; approval is earned." The default is to flag; approval must be earned. These are its ten checked standards and the concrete triggers SKILL.md marks for immediate flagging.
Standard 01 · Animations need a reason
Animations must serve spatial coherence, state indication, feedback, or explanation. 'It looks cool' is not a reason for frequently appearing elements.
Source · review-animations SKILL.md
Standard 02 · Frequency determines whether to animate
Actions triggered 100 or more times a day, such as keyboard shortcuts, should not animate. Occasional interactions can use standard animation; rare events may include surprise.
Source · emil-design-eng SKILL.md
Standard 03 · Correct entry and exit easing
Use ease-out or a custom curve for entry and exit. Built-in CSS easing is too weak; custom cubic-bezier curves are expected.
Source · review-animations SKILL.md
Standard 04 · No unjustified duration above 300ms
UI animations should not exceed 300 milliseconds without a valid reason. This is among the most common causes of a flagged review.
Source · review-animations SKILL.md
Standard 05 · Popovers expand from the trigger
Popovers should expand from their triggering element through transform-origin and never start from scale(0). Modals are the exception and remain centered.
Source · review-animations SKILL.md
Standard 06 · Gesture animations must be interruptible
Gesture-driven animations must redirect from their current state rather than restart keyframes from the beginning.
Source · review-animations SKILL.md
Standard 07 · GPU property animation limits
Animate only transform and opacity. Animating layout properties such as padding, margin, height, and width reduces performance.
Source · emil-design-eng SKILL.md
Standard 08 · Framer Motion hardware acceleration limits
x, y, and scale shorthand properties are not hardware accelerated. Use the full transform string, for example animate={{ transform: "translateX(100px)" }}.
Source · emil-design-eng SKILL.md
Standard 09 · Respect reduced-motion preferences
When prefers-reduced-motion is enabled, retain helpful opacity and color transitions while removing displacement and position animations. Isolate hover animations on mobile touch devices with @media (hover: hover) and (pointer: fine) to prevent accidental activation by taps.
Source · emil-design-eng SKILL.md
Standard 10 · Asymmetric entry and exit durations
Slow deliberate actions, such as holding for two seconds to delete with 2s linear. Immediate system responses should be fast, such as 200ms ease-out on release.
Source · emil-design-eng SKILL.md · Sonner example
review-animations CSS review example
This is an illustrative scenario: you have written a dropdown entry animation and want the agent to review it against these standards. review-animations does not trigger automatically (disable-model-invocation: true), so name it explicitly. The fixed output has two parts: a findings table, followed by a classified Block / Approve verdict; SKILL.md prescribes this format.
$ You ›
Use review-animations to review this dropdown animation:
claude: Claude(review-animations)›
Part 1 — Findings
hl: | Before | After | Why |
| transition: all 400ms ease-in; | transition: transform 200ms ease-out; | Standard 07: animate only transform/opacity, do not use all |
| | | Standard 03: do not use ease-in for entry, use ease-out |
| | | Standard 04:400ms exceeds the 300ms limit without a valid reason |
| transform: scale(0); | transform: scale(0.95); opacity: 0; | Standard 05: entry must not start from scale(0) |
| transform-origin: center; | transform-origin: var(--radix-...); | Standard 05: non-modal components must expand from the trigger |
Part 2 — Verdict
hl: [Feel-breaking] ease-in entry + scale(0) → movement feels sluggish and abrupt
hl: [Performance] transition: all makes the browser monitor changes to every property
hl: [Accessibility] No prefers-reduced-motion handling found
Default to flagging; approval is earned.
Review results mapped to standards
Four parts of the same CSS change, each corresponding to a standard number in section 04. The reasons are concrete rules that can be identified and checked individually, rather than a vague "it feels wrong." The philosophy framework defines judgment standards and the review skill checks them, rather than leaving "taste" as an abstract description.
Animation skills' functional boundaries
Customizing team animation standards
Every SKILL.md is plain Markdown that you can edit directly. These are practical next steps.
Team integration options
1. Add team rules to review-animations. Open skills/review-animations/SKILL.md and supplement the ten standards with product-specific restrictions, such as a component library's easing conventions. Include trigger conditions and Block reasons.
2. Standardize team terminology with animation-vocabulary. Map familiar but imprecise designer descriptions to formal vocabulary terms and record them in design handoff documents. This reduces repeated clarification of phrases such as "that bouncing effect."
3. Decide where review enters the workflow. Because review-animations does not trigger automatically, teams can invoke it manually for every PR or enforce it through a CI script. Both are reasonable, depending on team size.
4. Read demonstrations on the official website. emilkowal.ski/skill usually has more current demonstrations and explanations than the README. Revisit it periodically to check for rule updates.
Further reading
① skills/emil-design-eng/SKILL.md: Complete judgment framework, component principles, and performance rules. ② skills/review-animations/SKILL.md: Ten mandatory standards and immediate flagging triggers. ③ skills/animation-vocabulary/SKILL.md: Complete animation vocabulary categories. ④ emilkowal.ski/skill: The author's official introduction page.
Knowing whether you made a right choice when it comes to animations, or design in general, is hard.