motion-review-gate

name	motion-review-gate
description	Review frontend motion and animation code before shipping, with strict checks for purpose, frequency, easing, duration, transform origin, interruptibility, GPU-safe properties, reduced-motion support, and hover behavior. Use when a diff touches transitions, keyframes, Framer Motion, Lottie, drawers, popovers, toasts, hover or press states, gesture motion, or branded motion assets.
license	MIT
metadata	{"abvx_status":"experimental","abvx_origin":"adapted"}

Motion Review Gate

Review motion as a pre-ship gate. This skill does not design a whole interface and does not rewrite unrelated frontend code.

Use it after implementation or during review when the diff includes animation, transitions, gestures, Lottie assets, interaction states, or motion-heavy UI polish. Pair it with browser-verification when the visual behavior must be checked in a real browser. When a diff includes drag, swipe, momentum, snap points, or another direct-manipulation gesture, also run fluid-interaction-review; this gate alone does not fully verify gesture physics.

Use For

• CSS transitions, keyframes, @starting-style, WAAPI, Framer Motion, Motion, or Lottie changes;
• drawers, popovers, menus, dropdowns, tooltips, toasts, command palettes, modals, hover states, press states, and gestures;
• frontend diffs where animation might hurt speed, accessibility, or product feel;
• checking whether motion should be removed rather than polished.

Do Not Use For

• general frontend critique without motion-specific risk;
• visual hierarchy, brand direction, or typography review without interaction/motion changes;
• full accessibility or performance audits beyond animation-related issues.

Review Order

1. Purpose — every animation must serve feedback, spatial consistency, state indication, explanation, or prevention of jarring change.
2. Frequency — keyboard-triggered and 100+ times/day actions should not animate; frequent actions should be reduced.
3. Timing and easing — most UI motion stays under 300ms; avoid ease-in for UI response; prefer strong ease-out or appropriate custom curves.
4. Physicality — avoid scale(0); popovers, menus, and tooltips should originate from their trigger; modals can stay centered.
5. Interruptibility — rapidly triggered UI should retarget smoothly; prefer transitions or springs over restart-prone keyframes.
6. Performance — animate transform and opacity; avoid layout properties and parent CSS-variable recalc storms.
7. Accessibility — respect prefers-reduced-motion; gate hover motion behind real hover media queries.
8. Cohesion — motion should match the product surface: crisp for dashboards, more expressive only when the brand or moment earns it.

Hard Blocks

Flag these as blockers unless the diff clearly justifies them:

• transition: all;
• scale(0) entrance motion;
• ease-in on UI interactions;
• animation on keyboard shortcuts, command palettes, or other high-frequency actions;
• UI animation over 300ms without product reason;
• trigger-anchored popovers, menus, dropdowns, or tooltips scaling from center;
• keyframes on rapidly triggered dynamic UI like toasts or toggles;
• animation of width, height, margin, padding, top, left, or similar layout properties;
• missing reduced-motion handling for movement;
• ungated hover motion that can fire on touch devices.

Fix Preference

Prefer the smallest correction that removes the regression:

1. delete motion that should not exist;
2. reduce distance, duration, or animated properties;
3. fix easing and duration;
4. fix origin and entry scale;
5. make the motion interruptible;
6. move it to GPU-safe properties;
7. add reduced-motion and hover gating;
8. add polish only after the functional motion is correct.

Output Format

Return a findings table first:

Severity	Evidence	Fix	Why
block / high / medium / low	file:line and current behavior	concrete replacement or removal	user-facing reason

Then include:

• Decision: Block, Needs changes, or Approve.
• Verification: what to check in browser, including reduced-motion and touch/hover behavior when relevant.

Keep the review narrow. If the diff has no material motion risk, say that and approve the motion layer.

Attribution

Adapted from Emil Kowalski's public design engineering and animation-review guidance in emilkowalski/skills and animations.dev, re-shaped into ABVX's compact review-gate format.