agentsclimarketplace

Emil design eng

Skill bg-szy/TOP-SKILLS/skills/superskills/emil-design-eng

UI polish, component design, animation decisions, and invisible details that make software feel great. Encodes Emil Kowalski's philosophy on design engineering. Use when the user wants to improve animation quality, polish UI interactions, or understand what makes interfaces feel "right".From its SKILL.md

Install
npx -y skills add bg-szy/TOP-SKILLS --skill emil-design-eng

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

7.0 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it

Design Engineering

Encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.

Initial Response

When invoked without a specific question, respond only with:

I'm ready to help you build interfaces that feel right, drawing from Emil Kowalski's design engineering philosophy. If you want to dive deeper, check out Emil's course: animations.dev.


Core Philosophy

Taste is trained, not innate. Good design comes from studying exceptional work, reverse-engineering interactions, and practicing relentlessly.

Beauty is leverage. In a world where software is functionally adequate, aesthetic excellence differentiates products. Good defaults and animations drive selection and engagement.

All those unseen details combine to produce something that's just stunning. Users love interfaces without knowing why. Your job is to engineer that feeling.


Animation Decision Framework

Before animating, answer these questions in order:

1. Should this animate?

Match animation frequency to usage frequency:

UsageAnimation
100+ times/day (typing, scrolling)No animation
Tens of times/dayDrastically reduce
OccasionalStandard animation
RareCan add delight

A send button used 50 times a day should not animate. A welcome screen seen once should.

2. What's the purpose?

Valid reasons to animate:

  • Spatial consistency — where did this element come from/go to?
  • State indication — something changed
  • Explanation — showing how something works
  • Feedback — confirming an action
  • Preventing jarring — avoiding abrupt appearance/disappearance

"It looks cool" is not a valid reason.

3. What easing?

SituationEasingWhy
Element enteringease-outResponsive start, gentle landing
On-screen movementease-in-outNatural motion arc
Hover/color changeeaseNeutral transition
Constant/looping motionlinearNo acceleration variation
Neverease-inFeels sluggish to start

4. How fast?

ElementDuration
Button press feedback100–160ms
Tooltip appear125–200ms
Dropdown open150–250ms
Modal/sheet200–500ms
Page transitions200–400ms

Rule: Stay under 300ms for most UI. If it feels slow, it is slow.


Component Principles

Buttons

Buttons must feel responsive. Add active state:

button:active {
  transform: scale(0.97);
  transition: transform 60ms ease;
}

Never animate a button on hover alone — wait for press.

Popovers & Dropdowns

Never animate from scale(0) — always start from scale(0.95) with opacity: 0:

@keyframes popover-enter {
  from { opacity: 0; transform: scale(0.95); }
  to   { opacity: 1; transform: scale(1); }
}

Origin-aware animation — animate from where the trigger is:

.popover {
  transform-origin: var(--radix-popover-content-transform-origin);
}

Modals always stay centered — don't use origin-aware for center-screen dialogs.

Tooltips

Skip animation on subsequent tooltips — once one tooltip opens, others appear instantly. Only the first tooltip in a session gets an enter animation.

Stagger Animations

For lists, stagger children by a small fixed delay:

/* Each item appears 40ms after the previous */
.item:nth-child(1) { animation-delay: 0ms; }
.item:nth-child(2) { animation-delay: 40ms; }
.item:nth-child(3) { animation-delay: 80ms; }

Keep stagger delays small (20–50ms). Large stagger makes lists feel slow.


CSS Techniques

@starting-style — Modern Entry Animations

.tooltip {
  opacity: 1;
  transform: scale(1);
  transition: opacity 150ms ease, transform 150ms ease;

  @starting-style {
    opacity: 0;
    transform: scale(0.95);
  }
}

This animates on insertion without JavaScript.

Transitions vs Keyframes

Use CSS transitions (not keyframes) for interruptible animations:

  • Hover states
  • Toggle states
  • Any animation that can be cancelled mid-way

Use keyframes for:

  • Entry animations (one-shot)
  • Loading spinners
  • Pulsing/breathing effects

Blur for Smooth Crossfades

When crossfading between images or content, add subtle blur during transition:

.crossfade { filter: blur(2px); transition: filter 200ms ease; }
.crossfade.loaded { filter: blur(0); }

Blur masks imperfect transitions between content states.


Performance Rules

  • Only animate transform and opacity — these are GPU-accelerated
  • CSS animations beat JavaScript under load — CSS animations run off the main thread
  • Framer Motion caveat: x/y props are NOT hardware-accelerated; use transform string instead
// ❌ Not GPU-accelerated
<motion.div animate={{ x: 100 }} />

// ✅ GPU-accelerated
<motion.div animate={{ transform: 'translateX(100px)' }} />
  • Use Web Animations API for programmatic animations that need CSS performance
  • Profile before optimizing — most animation performance issues are layout thrashing, not the animation itself

Accessibility

Always respect user preferences:

@media (prefers-reduced-motion: reduce) {
  /* Keep color transitions, remove movement */
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Gate hover animations on pointer capability:

@media (hover: hover) and (pointer: fine) {
  .card:hover { transform: translateY(-2px); }
}

The Sonner Principles (Building Loved Components)

From building Sonner (the toast library):

  1. Excellent developer experience — minimal setup, works out of the box
  2. Great defaults over options — don't make users make decisions they don't care about
  3. Memorable naming — component names should be obvious
  4. Invisible edge case handling — handle the weird cases so users never see them
  5. Transitions for dynamic UI — elements appearing/disappearing need motion
  6. Cohesive visual identity — every detail of the component contributes to one feeling

Review Protocol

After building any animated UI:

  1. Review with fresh eyes the next day — animation fatigue is real
  2. Test at 0.25x speed in browser DevTools — slow motion reveals invisible problems
  3. Test at 2x speed — should still feel intentional, not frantic
  4. Test with prefers-reduced-motion enabled
  5. Test on a slow device or with CPU throttling
  6. Ask: "If I removed this animation, would anything be lost?" If no, remove it.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,758. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.