Plan purposeful UI microinteractions

Turn a component and its real state changes into a motion specification covering timing, interruption, input modes and reduced motion. A compact direction to help the next screen feel deliberate, specific, and easy to remix.

Design purposeful microinteractions for the specified Web component. Decide whether movement is useful before delivering a handoff specification. Default to a specification, without code or a site-wide motion overhaul.

INPUT
Required: [component and task: button, dialog, notification, etc.; user action and the change users need to understand]
Required: [real states: initial, triggered, pending, success, failure or exit; which actually exist]
Required: [materials: screenshots, description or code; known triggers and usage frequency]
Optional: [constraints: existing timing/easing tokens, component library, stack, brand character, target browsers]
Optional: [deliverable: specification only; or explicitly requested minimal implementation in supplied code]

METHOD
1. Confirm component scope, task and real states. Ask up to three blocking questions and wait; mark other gaps [to supply]. Screenshots cannot establish timing, hidden states, focus or gestures. Label frequency assumptions rather than inventing usage data.
2. Name each transition's purpose: feedback, state indication, spatial relationship or continuity. Prefer instant feedback or very subtle transitions for frequent actions. Do not move data users are reading or acting on for decoration. Keep states static when movement has no clear purpose, explaining why. Keyboard actions and focus must not wait for animation.
3. Specify entry, change and exit for actual states. Reuse existing tokens first. Treat press feedback 100–160ms, small popovers 125–200ms, dropdowns 150–250ms and dialogs/drawers 200–500ms as source experience ranges, not standards or measured results. Prefer ordinary interactions below 300ms and justify longer motion. Choose a concrete proposed value with units and rationale rather than only listing options.
4. Define properties, direction, magnitude, easing and origin. Prefer ease-out for entry/exit and ease-in-out for movement within the screen. Anchor popovers to their triggers; centered dialogs may use a central origin. Avoid scale(0) and transition: all. Prefer transform/opacity without guaranteeing GPU acceleration or performance. Rapid retriggers should continue from the current visual state. Define reversal, interruption, exit and final business state. Use indeterminate progress when completion is unknown.
5. Include prefers-reduced-motion and touch/mouse/keyboard behavior. Reduce translation, scaling and parallax; preserve essential feedback through text, color or instant changes. Hover enhances only fine pointers that support it; other inputs must complete the task. Preserve component semantics, focus and dismissal. Give minimal code only when requested with sufficient code/stack; add no unnecessary dependency and never advance business logic solely on animation-end events. Check retriggers, reversal, loading failures and reduced motion. Without execution, mark checks unverified.

DELIVER IN ORDER
A. Motion decisions: component / purpose / known frequency or assumption / animate or remain static / reason.
B. State/motion table: start→target / trigger / properties and magnitude / timing and easing / origin / interruption and exit / business state.
C. Input/reduced-motion table: mouse / touch / keyboard / reduce; visible feedback, operability and focus requirements.
D. Only if requested: minimal implementation, reused tokens and change locations; distinguish examples from actual edits.
E. Verification list: action / expected / actual / unverified reason; recommend playback or frame-by-frame checks and real-device gestures where needed, without fabricated frame rates or device results.

BOUNDARIES
No full component library, native App motion or video. Preserve business state machines, APIs and feedback meaning. Proposed parameters are not evidence of playback, performance tests or accessibility certification.

Independent site adaptation of Emil Kowalski / skills, animate and recipes (MIT). Retains purpose, timing, interruption and reduced-motion methods; adds specification-first delivery and evidence boundaries. Not the complete Skill: https://github.com/emilkowalski/skills/blob/e8a175de22ae1e49370fc144c1f3bb9aeedf988d/skills/animate/SKILL.md .

decorative movement of task data, keyboard actions waiting for animation, invented progress, missing reduced-motion behavior, hover-only feedback, transition: all, animation-end-dependent business logic, fabricated performance results