Apply Motion Personality Seeds to React Components

Applies a named StyleSeed motion to a React component - either one of five personality seeds (Spring, Silk, Snap, Float, Pulse, each spanning entrance/exit/hover/press/layout variants) or a distinctive keyword move from a motion library (toggle-flip, reveal-blur, shimmer, and similar) - translating a described vibe or use case into framer-motion JSX.

It maps user vocabulary to a seed via a lookup table from engine/motion/index.ts: bouncy/springy/playful -> Spring, smooth/silky/fluid -> Silk, snappy/quick/decisive -> Snap, floaty/gentle/weightless -> Float, rhythmic/punchy/pulsing -> Pulse, plus brand-style cues (Toss/Arc -> Spring, Stripe/Notion -> Silk, Linear/Raycast/Vercel -> Snap) and an explicit BRAND_DEFAULT_SEED fallback. In "recommend mode," when the user describes a use case rather than a feeling, it consults a MOTION_BY_USECASE map - e.g. a primary CTA press reaches for spring · press, a modal entrance for silk · entrance, a dropdown for snap · entrance, a like/favorite reaction for like-burst, a live indicator for pulse-beat, loading for shimmer - governed by two anti-rules: one seed per product (never introduce a second personality if one is already established), and never delay the payload (never animate a balance, price, or search result into view).

For distinctive named moves, engine/motion/library.ts (exported as MOTION_LIBRARY/MOTION_BY_KEY) is the single source of truth - each keyword (e.g. toggle-flip for a 3D card flip, reveal-blur for a focus-pull, pop-in for a spring-overshoot badge, wiggle for error feedback) carries its own calibrated, runnable snippet that must be copied verbatim, never hand-written. Context (hover/press/entrance/exit/layout) is inferred from phrases like "on hover," "when it appears," or "when it leaves" (which requires <AnimatePresence>), defaulting to entrance if ambiguous, or applying multiple contexts together when more than one is reasonable (e.g. a button needing both hover and press).

// hover example
<motion.button {...spring.hover}>Save</motion.button>

// press + hover combined
<motion.button {...spring.press} {...spring.hover}>Save</motion.button>

// entrance (mount)
<motion.div {...silk.entrance}>...</motion.div>

// exit (requires AnimatePresence wrapper somewhere up the tree)
<AnimatePresence>
  {open && <motion.div {...silk.entrance} {...silk.exit} />}
</AnimatePresence>

// layout (FLIP)
<motion.div {...snap.layout}>...</motion.div>

Application steps: read the target file and locate the JSX element, confirm motion/AnimatePresence import from framer-motion and the seed import from @engine/motion, replace the tag with <motion.X> spreading the seed's recipe (never inlining the transition params by hand), respect prefers-reduced-motion for long-running mount/exit/layout sequences via usePrefersReducedMotion/REDUCED_TRANSITION, validate the file still parses, and tell the user which seed/context was applied. If vague, it defaults to Silk (the safest seed) for a general "feel like a real app" ask, and adds press automatically for CTA buttons.

Use it when applying framer-motion JSX animation to a React component from a described vibe or use case. Not for general framer-motion learning (use its docs), non-React motion like CSS-only transitions or GSAP, scroll-linked timelines or parallax (out of scope per DESIGN-LANGUAGE.md Rule 59), or tweaking the existing FadeIn/FadeUp/Stagger wrappers (edit engine/components/ui/motion.tsx directly instead). Never invents a seed name (exactly five exist) or a keyword not in the library, and never introduces a third-party animation library.

Input is a target file/element, a described vibe, use case, or explicit seed/keyword name, and the desired context (hover/press/entrance/exit/layout). Output is the target JSX element rewritten as a <motion.X> tag spreading the matched seed's or keyword's recipe, with required imports confirmed.

Targets motion.X JSX from framer-motion exclusively, pulling seed and keyword recipes from @engine/motion (engine/motion/index.ts, library.ts, seeds/*.ts) as the single source of truth.

Developers implementing UI motion who want a consistent, calibrated animation applied from a described feeling or interaction moment, rather than hand-tuning framer-motion transition values per component.