motion-design-toolkit
Installation
SKILL.md
Motion Design Toolkit Skill (GSAP · Framer Motion · Lottie)
Three motion libraries, one decision framework — pick the right tool per job instead of defaulting to whichever is most familiar.
Which library for which job
| Need | Use |
|---|---|
| Scroll-triggered sequences, timelines, pinning, complex choreography, SVG morphing | GSAP (+ ScrollTrigger) |
| React-idiomatic component animation, layout/shared-element transitions, gestures (drag/hover/tap), page transitions in Next.js | Framer Motion (motion/react) |
| Designer-exported vector animations (After Effects → Lottie JSON) — icons, illustrations, success/loading states | Lottie (lottie-react / @lottiefiles/dotlottie-react) |
Don't reach for GSAP inside every component for simple enter/exit — that's Framer Motion's job. Don't reimplement a designer's AE animation by hand — that's Lottie's job. Don't fight Framer Motion's declarative model for a 12-step pinned scroll sequence — that's GSAP's job.
Cross-cutting rules (apply regardless of library)
- Respect
prefers-reduced-motion— every non-essential animation gets a reduced/skipped variant. Checkwindow.matchMedia('(prefers-reduced-motion: reduce)')and gate accordingly. - Animate cheap properties:
transform(translate/scale/rotate) andopacityonly for anything performance-sensitive or scroll-linked — never animatetop/left/width/height/box-shadowin a hot loop (forces layout/paint). - Clean up on unmount: kill GSAP timelines/ScrollTriggers and Framer Motion animation controls when a component unmounts, especially in Next.js route transitions — orphaned ScrollTriggers are the #1 source of "animation still running on a page I left" bugs.
- One driver per property — don't have GSAP and Framer Motion (or CSS transitions) fighting over the same element's
transform.