Improve or implement purposeful motion systems, micro-interactions, gestures, and transition behavior for production-grade UI. Use when the user mentions animation, motion, transitions, micro-interactions, hover states, drawers, toasts, gestures, or making the UI feel more alive.

Analyze a feature and add motion that improves clarity, feedback, perceived performance, and polish without making the interface feel slow, noisy, or theatrical. MANDATORY PREPARATION Users start this workflow with /animate . Once this skill is active, load $frontend design — it contains design principles, anti patterns, and the Context Gathering Protocol . Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: performance constraints. Consult the [motion reference](../frontend design/reference/motion design.md) for timing, easing, choreography, and reduced motion handling. Consult the [animate reference index](reference/README.md) when you need to browse the deeper motion library by use case instead of guessing filenames. Consult the [elevation system](../frontend design/reference/elevation system.md) when motion should reinforce raised, pressed, inset, dragged, or layered depth. Consult the [interaction reference](../frontend design/reference/interaction design.md) when animation decisions overlap with focus, loading, transitions, or feedback states. Consult the [component anatomy reference](../frontend design/reference/component anatomy.md) when motion affects custom primitives such as buttons, tabs, tooltips, toasts, toggles, drawers, or submit actions. Consult the [responsive design reference](../frontend design/reference/responsive design.md) when motion needs to adapt across small screens, touch contexts, or reduced viewport space. Consult the [framework official docs reference](../frontend design/reference/framework official docs.md) before making framework specific animation decisions. Consult the [React shadcn accelerators reference](../frontend design/reference/react shadcn accelerators.md) when the request overlaps with React toasts, drawers, text motion, or other UI patterns that already have strong accelerators. Consult the [CSS, Tailwind, and WAAPI motion reference](../frontend design/reference/css tailwind and waapi motion.md) to decide when modern CSS, Tailwind, or WAAPI can solve the motion cleanly without reaching for a framework animation library. Consult the [scroll driven animations reference](../frontend design/reference/scroll driven animations.md) when motion should progress with scroll position rather than time. Consult the [view transitions reference](../frontend design/reference/view transitions.md) when animating between page states or DOM changes with shared element continuity. Consult [attribution and sources](reference/attribution and sources.md) for the source lineage behind this skill's Emil inspired motion guidance. Consult [entrance animations](reference/entrance animations.md), [exit animations](reference/exit animations.md), [gesture interactions](reference/gesture interactions.md), and [micro interactions](reference/micro interactions.md) for consolidated thematic guidance by motion type. Consult [ease out defaults](reference/ease out default.md), [easing by context](reference/easing context.md), and [custom easing curves](reference/custom easing curves.md) when choosing motion curves. Consult [UI under 300ms](reference/ui under 300ms.md), [asymmetric press and release timing](reference/asymmetric press release.md), [500ms drawer timing](reference/drawer 500ms duration.md), [faster perceived performance](reference/faster improves performance.md), and [tooltip timing escalation](reference/tooltip delay instant followups.md) when the main question is duration rather than easing. Consult [on screen movement easing](reference/ease in out on screen movement.md), [sheet and drawer easing](reference/sheet drawer easing.md), and [spring motion](reference/spring motion.md) when the motion pattern needs more specific guidance. Consult [damped drag boundaries](reference/damp drag boundaries.md), [upward drag friction](reference/upward drag friction.md), [interruptible animations](reference/interruptible animations.md), [momentum dismissal](reference/momentum dismissal.md), [pointer capture](reference/pointer capture.md), [scroll and drag conflicts](reference/scroll drag conflicts.md), and [velocity aware snap points](reference/velocity aware snap points.md) when implementing gesture heavy surfaces. Consult [blur bridged transitions](reference/blur bridge states.md), [clip path tabs](reference/clip path tab transitions.md), [respect reduced motion](reference/respect reduced motion.md), [opacity fallback](reference/opacity reduced motion fallback.md), [reduced motion alternatives](reference/reduced motion not zero.md), [Motion's useReducedMotion ](reference/use reduced motion hook.md), [hover gap fill](reference/hover gap fill.md), [scroll reveal thresholds](reference/scroll animation threshold.md), [child orchestration](reference/stagger children orchestration.md), and [toast stack depth](reference/toast stack depth.md) for polish and accessibility refinement. Consult [transform and opacity only](reference/transform opacity only.md), [avoid CSS variables in drag loops](reference/avoid css variables drag.md), [clip path reveals](reference/clip path layout free reveals.md), [hardware accelerated motion under load](reference/hardware accelerated busy main thread.md), and [surgical will change ](reference/will change subpixel shift.md) for performance sensitive property choices. Consult [immediate action feedback](reference/immediate feedback actions.md), [interaction frequency](reference/interaction frequency.md), [no keyboard animation](reference/no animation for keyboard.md), [marketing exceptions](reference/marketing exception.md), and [animation purpose](reference/animation purpose.md) for strategy heavy motion decisions. Consult [preserve 3d effects](reference/preserve 3d effects.md), [never scale from zero](reference/never scale zero.md), [origin aware animations](reference/origin aware animations.md), and [percentage translateY](reference/percentage translate y.md) when the question is really about transform technique and spatial feel. Consult [button press scale 0.97](reference/button press scale 097.md), [scale affecting children](reference/scale affects children.md), and [SVG path morph disclosure icons](reference/svg path morph disclosure.md) for finer transform polish details. If the interface already feels laggy under frequent use, also load optimize . If the interface needs stronger resilience around reduced motion, errors, overflow, edge cases, or mixed input modes, also load harden . Attribution and Inspiration This skill's motion guidance is informed in part by [Emil Kowalski's animations.dev course](https://animations.dev/), especially the emphasis on easing choice, timing, tasteful restraint, springs, and motion that "feels right" in production UI. It is also informed by Emil's animation heavy open source work on [Sonner](https://github.com/emilkowalski/sonner) and [Vaul](https://github.com/emilkowalski/vaul), which are already relevant elsewhere in this library for React toast and drawer guidance. This repository rewrites those lessons into original, repository specific guidance rather than reproducing the course materials directly. Motion Operating Model Use this decision order before adding any animation: 1. Fix structure first — motion should reinforce hierarchy and state, not rescue a confusing layout. 2. Animate only with a job to do — every animation should improve feedback, orientation, relationship, or delight. 3. Bias toward speed — product UI should feel responsive first and impressive second. 4. Keep motion interruptible — new user intent beats finishing the old animation. 5. Match the input method — mouse, touch, and keyboard interactions do not all deserve the same motion treatment. 6. Plan reduced motion up front — accessibility is part of the system, not a cleanup pass. 7. Prefer the lightest implementation that fits — modern CSS and Tailwind first, WAAPI when imperative timing matters, Motion when the interaction genuinely needs it. Use motion for one or more of these jobs: Feedback — acknowledge that an action happened Orientation — help users understand where something came from or where it went Relationship — show how surfaces, layers, and controls relate spatially Delight — add warmth or personality after the fundamentals already work If the animation cannot justify itself with one of those jobs, cut it. Assess Motion Opportunities Analyze where motion would improve the experience: 1. Identify static areas : Missing feedback : Actions without visual acknowledgment (button clicks, form submission, etc.) Jarring transitions : Instant state changes that feel abrupt (show/hide, page loads, route changes) Unclear relationships : Spatial or hierarchical relationships that aren't obvious Lack of delight : Functional but joyless interactions Missed guidance : Opportunities to direct attention or explain behavior 2. Understand the context : What's the personality? (Playful vs serious, energetic vs calm) What's the performance budget? (Compact layout first? Complex page?) Who's the audience? (Motion sensitive users? Power users who want speed?) What matters most? (One hero animation vs many micro interactions?) Which inputs matter? (mouse, touch, keyboard, stylus) Which interactions are high frequency and should stay especially snappy? If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer. CRITICAL : Respect prefers reduced motion . Always provide non animated alternatives for users who need them. Motion should reinforce hierarchy, not compensate for weak hierarchy. If the layout only becomes understandable once it moves, fix the layout first. Plan Animation Strategy Create a purposeful animation plan: Hero moment : What's the ONE signature animation? (Page load? Hero section? Key interaction?) Feedback layer : Which interactions need acknowledgment? Transition layer : Which state changes need smoothing? Gesture layer : Which drag, swipe, snap, or dismiss interactions need physical logic? Delight layer : Where can we surprise and delight? Depth logic : Which elements should feel raised, pressed, dragged, inset, or layered? Reduced motion plan : What simplifies to fade, blur, or instant state change? Performance budget : Which motions must stay lightweight because they happen often? IMPORTANT : One well orchestrated experience beats scattered animations everywhere. Focus on high impact moments. Default Motion Rules Use these as the default guidelines for animation work unless the product context gives a strong reason to deviate. 1. Strategy and Purpose Every animation must earn its place through feedback, orientation, relationship, or delight . Product interfaces should usually feel fast, calm, and precise . Save slower or more dramatic motion for onboarding, hero moments, storytelling, or marketing surfaces. Favor one signature moment plus disciplined micro interactions over adding motion everywhere. Do not animate keyboard initiated actions just because pointer interactions animate. Keyboard users usually want predictable state change with minimal delay. The more often an interaction happens, the less motion it usually needs. High frequency controls should feel nearly instant. Acknowledge user input immediately. Aim for visible feedback within roughly 80ms for micro interactions whenever possible. If real work may exceed roughly 400ms , respond immediately with optimistic UI, skeletons, progress, or clear loading feedback instead of leaving a dead pause. Never use motion to disguise slow loading, weak hierarchy, or missing state design. 2. Easing Defaults Use ease out as the default for entrances, reveals, and most feedback transitions. Use custom cubic bezier curves instead of the generic CSS