motionkit

Motion goes wrong in ways no test catches: an entrance that eases in, a popover that grows from scale(0) at its own center, a toast whose keyframes restart when a second toast arrives, a command palette that fades in fifty times a day. Each makes an interface feel slower or cheaper than it is.

motionkit holds one body of rules for those choices, the motion standard, and three modes that apply it. uikit (when installed) decides whether motion fits a screen's design read. motionkit decides how that motion moves.

When this fires

Route by the verb in the ask, read that mode's file, then follow it. Everything in this root applies to every mode; the mode files do not repeat it.

build. "Animate this dropdown", "add a press effect", "make the drawer slide in", "fix this transition". The verbs "fix", "add", "make", and "animate" run it. It writes code. Mode build → read modes/build.md, then follow it.
review. "This animation feels off", "check the motion in this diff", "audit the animations in this app", "what should animate here". "Feels off", "check", "review", "audit", and a motion ask with no verb run it. It writes nothing. A change gets findings and a verdict; a codebase sweep gets a ranked list of fixes and missing motion, with one item crowned. Mode review → read modes/review.md, then follow it.
perf. "This transition is janky", "the drawer stutters", "the list drops frames". It names the cause of each dropped frame and writes nothing until the user asks for the fixes. Mode perf → read modes/perf.md, then follow it.
lookup. "What's it called when an element slides in and settles". It needs no file. Follow The lookup branch.

Two phrases cross the verb split. "Make the app feel alive" runs review at sweep scale, because it asks where motion belongs. "Fix the jank" runs perf, because the cause comes before any code change.

Not this skill. General UI taste is uikit's. React Native, Expo, native platforms, WebGL, canvas, and scroll-driven marketing scenes are out of scope; say so in one line and stop.