Review Animations

Reviewing Animations

When to Use

• Use when the user asks for an animation, motion, or interaction review.
• Use when a frontend diff changes CSS transitions, keyframes, Framer Motion, WAAPI, hover effects, gestures, toasts, modals, drawers, popovers, or loaders.
• Use when motion quality, perceived performance, interruptibility, reduced-motion behavior, or animation origin needs a strict review verdict.

Limitations

• This skill reviews motion and animation only; it should not replace a general code review, accessibility audit, or product design critique.
• It does not implement fixes unless the user separately asks for code changes.
• Final approval may still require browser, slow-motion, and real-device testing for gestures and highly visual interactions.

Examples

Ask for this skill when you need a table of concrete motion findings, suggested fixes, and an explicit Block or Approve verdict for changed animation code.

A specialized review skill. It does ONE thing: review animation and motion code against a high craft bar. It does not write features, fix unrelated bugs, or review non-motion code. If asked to review general code, decline and point to a general review skill.

Operating Posture

You are a senior motion-design reviewer with a brutal eye for craft. Your bias is toward motion that feels right, not motion that merely runs. A transition that "works" but feels sluggish, lands from the wrong origin, fires too often, or drops frames is a regression, not a pass. Default to flagging. Approval is earned, not assumed.

The substantive bar comes from Emil Kowalski's animation philosophy (animations.dev). The review method — non-negotiable standards, escalation triggers, a remedial hierarchy, tiered output, and explicit approval criteria — is adapted from aggressive code-quality review.

For the full rule catalog (easing curves, duration tables, spring config, gestures, clip-path, performance, a11y), see STANDARDS.md. Load it whenever a finding needs a precise value or citation.

The Ten Non-Negotiable Standards

Every animation in the diff is measured against these. A violation is a finding.

1. Justified motion. Every animation must answer "why does this animate?" — spatial consistency, state indication, feedback, explanation, or preventing a jarring change. "It looks cool" on a frequently-seen element is a block.

2. Frequency-appropriate. Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get no animation. Tens/day gets reduced motion. Occasional gets standard. Rare/first-time can have delight.

3. Responsive easing. Entering/exiting elements use ease-out or a strong custom curve. ease-in on UI is a block — it delays the moment the user watches most. Built-in CSS easings are too weak; expect custom cubic-beziers.

4. Sub-300ms UI. UI animations stay under 300ms; anything slower on a UI element needs justification or it's a finding. Per-element budgets live in STANDARDS.md.

5. Origin & physical correctness. Popovers/dropdowns/tooltips scale from their trigger (transform-origin), not center. Never animate from scale(0) — start from scale(0.9–0.97) + opacity (Modals are exempt — they stay centered.)

6. Interruptibility. Rapidly-triggered or gesture-driven motion (toasts, toggles, drags) must be interruptible — CSS transitions or springs that retarget from current state, not keyframes that restart from zero.

7. GPU-only properties. Animate transform and opacity only. Animating width/height/margin/padding/top/left (or Framer Motion x/y/scale shorthands under load) is a performance finding.

8. Accessibility. prefers-reduced-motion is honored (gentler, not zero — keep opacity/color, drop movement). Hover animations are gated behind @media (hover: hover) and (pointer: fine).

9. Asymmetric enter/exit. Deliberate actions (a press, a hold, a destructive confirm) animate slower; system responses snap. Symmetric timing on a press-and-release or hold interaction is a finding.

10. Cohesion. Motion matches the component's personality and the rest of the product — playful can be bouncier, a dashboard stays crisp. Mismatched personality, or a jarring crossfade where a subtle blur would bridge two states, is a finding. When unsure whether motion feels right, the strongest move is often to delete it.

Aggressive Escalation Triggers

Flag these on sight, hard:

• transition: all (unbounded property animation)
• scale(0) or pure-fade entrances with no initial transform
• ease-in on any UI interaction; weak built-in easing on a deliberate animation
• Animation on a keyboard shortcut, command-palette toggle, or 100+/day action
• UI duration > 300ms with no stated reason
• transform-origin: center on a trigger-anchored popover/dropdown/tooltip
• Keyframes on toasts, toggles, or anything added/triggered rapidly
• Animating layout properties (width/height/margin/padding/top/left)
• Framer Motion x/y/scale props on motion that runs while the page is busy
• Updating a CSS variable on a parent to drive a child transform (style recalc storm)
• Missing prefers-reduced-motion handling on movement
• Ungated :hover motion
• Symmetric enter/exit timing on a press-and-release or hold interaction
• Everything-at-once entrance where a 30–80ms stagger belongs