Review Motion Handoff

Audit an animation implementation on two axes: fidelity (does it match what was designed?) and quality (is it performant, accessible, and idiomatic?). Output a findings table, not a rewrite.

Inputs

Best case: Figma Motion Dev Mode JSON (ground truth for times, values, curves) plus the implementation code. If only a Figma frame link is available, call getmotioncontext (recursive) to obtain the keyframe data. If neither exists, say so and limit the review to the quality axis.

Fidelity checks (against the JSON / motion context)

Normalize before comparing: round beziers to 3 decimals (Figma emits float noise: 0.2199999988 is 0.22), convert timeMs to offsets (timeMs / timelineDurationMs), compute relative deltas (end - start) from canvas absolutes.

Hardcoded canvas coordinates in layout-dependent animations is a critical finding, it will break on any viewport other than the design frame.

Quality checks

Performance (full detail in the figma-motion-handoff skill, references/performance.md, and https://hub.joyco.studio/logs/12-the-render-pipeline plus /logs/11-wtf-is-layout-thrashing):

• Only transform/opacity on the hot path; no animated width/height/top/left/margin where a transform would do.
• Blur/filter animations: flag large blurred surfaces, suggest profiling; blur radius near the source value (12px on a big grid deserves a note).
• No getBoundingClientRect/layout reads inside scroll handlers or animation ticks; in projects with @joycostudio/metri, measurements go through the cache (getBounds, useBounds, useScrollCallback), and DOM-change-then-measure sequences use targeted refresh(el). Interleaved read/write is a critical finding (layout thrashing).
• If a custom scroll source (Lenis etc.) exists, scroll-linked values must come from it, not window.scrollY.
• will-change applied temporarily, not permanently.
• Reveal/scroll triggers driven through attribute- or class-selector CSS transitions ([data-visible="true"] { transition: ... }, .is-visible) are a major finding: selector flips force wide style recalculation (repaint path, hub render-pipeline log). The pass condition is an imperative start (WAAPI or the library) with the initial state server-rendered.
• GSAP: gsap.from/gsap.fromTo on SSR-visible content is a critical finding (from-values arrive after server HTML paints: guaranteed flash). Timeline not held in a ref, or created outside useGSAP (no cleanup), is a major finding. A ScrollTrigger created while Lenis or another custom scroller drives the page, without the scroller wired to ScrollTrigger.update and the ticker, is a major finding.

Accessibility:

• prefers-reduced-motion handled, and handled at the layer that wins: if JS drives inline styles, a CSS media query alone is defeated (see https://hub.joyco.studio/logs/13-working-with-reduced-motion). Spatial motion removed or reduced; opacity fades may remain.

Conventions:

• Easing/duration values exist as named tokens (CSS --ease-* theme variables in the global stylesheet for Tailwind projects, shared tokens module for Motion/anime.js), not inline magic numbers. Inline cubic-bezier() in component code is a finding even when the values are correct.
• Token names follow the classical easing conventions (ease-out-quart, ease-out-back), not values; descriptive names only for curves that are not classics.
• Duplicate near-identical curves consolidated into one token.
• Spring easings hand-copied as raw sampled functions ((t) => 1 - e^(-a*t)(...)) instead of translated to a named token (spring config, linear() token, createSpring, CustomEase) are a convention finding.

Taste (flag, do not block):

• Entrances ease out, exits ease in; linear reserved for progress/marquee-like loops.
• Duration sanity: micro-interactions under ~300ms; anything over 1s on a UI transition needs a reason (choreographed hero moments are a valid reason).
• Springs on interactive gestures, curves on choreography.

Output format

A findings table sorted by severity, then a verdict:

Close with: what is verified 1:1 against the source, what was correctly recomputed for layout, and whether the implementation is approved, approved with notes, or needs changes. Do not rewrite the implementation unless asked; the review's job is the diff.