emilkowalski-motion

# Emil Kowalski Motion Follow-Up Use this skill after a design artifact already exists. The goal is to make the interface feel alive without turning it into a motion demo. ## Workflow 1. Inspect the current HTML, component, or selected page element before adding animation. 2. Pick the smallest set of motion moments that clarify state or hierarchy: - entry reveal for the primary content - hover / active feedback for important controls - transition between UI states - scroll reveal only when it helps the story 3. Prefer `transform` and `opacity`. Avoid animating layout properties such as `top`, `left`, `width`, or `height`. 4. Use one motion language across the artifact. Do not mix unrelated easings, durations, or physics. 5. Add `prefers-reduced-motion` fallbacks for any automatic or scroll-linked motion. 6. Keep copy, data, and layout intent intact unless the user explicitly asks for a redesign. ## Motion Rules - Default UI transitions should feel quick and useful: 140-220ms for most controls. - Larger page reveals can be slower, but must not block reading. - Avoid endless decorative loops unless they communicate status or progress. - Do not add custom cursors, noisy particle effects, or motion that competes with content. - Stagger only small groups. Long staggered lists make interfaces feel slow. ## Implementation Notes - For plain HTML, CSS keyframes and small JavaScript observers are enough. - For React or framework code, use the local stack already present in the repo. - If GSAP is available and the motion needs sequencing, pair this with `gsap-core`, `gsap-timeline`, or `gsap-scrolltrigger`. - Always clean up observers, timers, and animation instances.