Design Engineering

Use when writing or reviewing web animation code - easing curves, durations, whether to animate at all, springs versus CSS transitions, swipe and drag dismissal, transform-origin on popovers, @starting-style, clip-path reveals, stagger - or when someone says "this animation feels off", "make it feel polished", "why does this dropdown feel slow". Encodes Emil Kowalski's craft bar from building Sonner and Vaul. Do NOT use for visual design such as color, type or layout - use interface-design; for motion tokens use animation-system; for video motion use motion-design-principles.

Review already-written animation or motion code against a strict craft bar and return a findings table plus a block or approve verdict. Use when someone asks "review my animations", "review the motion in this PR", "does this transition feel right", "why does this dropdown feel sluggish", or wants a pass/fail judgment on shipped motion code at file and line. Best run when you explicitly ask for it rather than on every diff - it is deliberately strict and approval is earned. Do NOT use to survey a whole codebase and produce a roadmap - use improve-animations; to design new motion from scratch use motion-design-principles; to check a build against a Figma spec use design-qa-checklist.

Use when someone asks to "improve the animations", "audit the motion in this codebase", "make this app feel better", "why does our UI feel janky", or wants a prioritized roadmap of animation fixes. Surveys a codebase's motion as a senior advisor, then writes self-contained implementation plans that other agents or cheaper models can execute. Read-only on source code - it plans improvements, it does not apply them. Do NOT use to review a single diff or PR - use review-animations; to find places that should animate but do not, use find-animation-opportunities; to build a motion token scale use animation-system.

Search a codebase or UI for places that do not animate but should, and reject everything that should not. Read-only - it proposes motion with exact values, it does not implement it. Use when someone asks "what could be animated here?", "nothing on this page moves", "what should NOT be animated", or wants to "make this feel more alive". This skill is about MISSING motion, and it is built to say no - most candidates are expected to be rejected. Do NOT use when motion already exists and feels wrong: for a roadmap of fixes use improve-animations, for reviewing a diff use review-animations.

Reverse-lookup glossary that turns a vague description of a web animation or motion effect into its exact term ("the bouncy thing when a popover opens" becomes Pop in; "the iOS rubber-band scroll" becomes Rubber-banding). Use when someone asks "what's it called when...", "what's the word for...", or describes an effect they cannot name and wants the right term to prompt an AI or a designer with. Naming only - do NOT use to choose easings, durations or spring values (use motion-design-principles), to build a motion token system (use animation-system), or to implement the effect.

Use when someone asks "what should I use for toasts / drag and drop / a command menu / a big list / animating a number", or is about to hand-roll a UI primitive that a good package already solves. Returns one opinionated pick per task from a curated list of libraries Emil Kowalski actually uses and trusts, with the npm specifier, instead of letting an agent invent a component or install an abandoned package. Best run when you explicitly ask for it. Do NOT use to debug or restyle a library already installed, to audit a dependency for CVEs or licensing, or to choose backend or data-layer packages.

Use when someone says "give me three versions of this pricing card", "build a few takes on the empty state and let me flip through them", or "prototype some variations of this button". Builds several genuinely different working versions of ONE component behind a live picker, then stops and lets you choose and promote the one that feels right. Requires a filesystem and ideally a dev server. Best run when you explicitly ask for it. Do NOT use to build a single component, to critique designs that already exist (use design-critique), to explore pre-code design direction (use interface-design), or to work through a whole multi-screen flow.