Find Animation Opportunities

Find animation opportunities

Find high-value motion by exercising restraint. A result with no surviving opportunities is valid; daily-use product UI usually benefits from less motion.

Triggers

• Use when asked what should animate, where motion would improve an otherwise static interface, or which proposed motion ideas are worth pursuing.
• Do not use to fix current animations, review a motion diff, or implement the recommendations; route those follow-ups to the existing motion skills.

Authority and boundaries

1. Read docs/ai/rules/frontend.md, then docs/ai/skills/emil-design-engineering/SKILL.md and docs/ai/skills/anim/SKILL.md before judging a surface.
2. Core's tokens, Base UI primitives, shared utilities, route-transition boundary, touch gates, and reduced-motion baseline override generic examples.
3. Use improve-animations to audit or plan fixes for existing motion and review-animations only for an explicitly requested motion-diff review. Use motion later if an approved implementation needs motion/react details.
4. This skill reports evidence and recipes only. Do not edit source, write plan files, install tooling, or change dependencies while it is active.

Candidate gate

Every recommendation must pass all five checks:

1. Frequency and input: Reject decorative motion on keyboard-initiated, high-frequency, or information-dense interactions. Frequent feedback may use an existing near-imperceptible Core utility; it is not a new opportunity.
2. Purpose: Name one purpose: feedback, spatial continuity, state clarity, preventing a jarring change, explanation, or rare delight. “Looks cool” fails.
3. User value: Motion must make cause/effect, hierarchy, progress, or state easier to understand. It must not delay access to content or action.
4. Existing ownership: Reject motion already supplied by Button, Base UI overlays, shared hover/press utilities, or RouteMainViewTransitionBoundary. Never stack a second entrance or hover grammar on top.
5. Core feasibility: The recipe must use existing motion tokens/presets, avoid layout-driving properties, remain interruptible where state can reverse, preserve reduced-motion behavior, and gate hover motion to fine pointers.

Workflow

1. Recon. Define the route/component scope, product personality, input methods, frequency, current motion owners, and performance/accessibility constraints. Inspect a running UI when available; otherwise state the limits of code-only evidence.
2. Sweep seams. Look for abrupt occasional state changes, unclear spatial relationships, missing progress/feedback, rare empty/success/onboarding moments, and gesture transitions. Also inspect the places most likely to be over-animated so the report contains meaningful rejections.
3. Gate candidates. Re-read every cited location and apply all five checks. Reject duplicates, speculative ideas, and anything already intentional.
4. Specify survivors. Report at most five opportunities, ordered by leverage. Name the existing Core token, preset, utility, or primitive to reuse. Do not invent literal durations, easings, scales, or a parallel motion system.
5. Report restraint. Include two to five rejected candidates and the exact gate that rejected each. If nothing survives, say that the interface should remain as-is.