Zoetrope

Motion that feels right is mostly motion that was allowed to exist for a reason, then built from the right few ingredients. This skill does three jobs with one shared test:

• Build - turn a request for motion into code.
• Review - judge existing motion, in a diff or across a whole codebase.
• Find - sweep an interface for the few places that should move, and reject the rest.

Pick the job from the request: "animate", "add a transition", "make this feel alive" is build; "review", "audit", "improve the animations" is review (the current diff unless the whole codebase or a path is named); "what should animate", "where could motion help" is find. State which job you are doing in one line, then do it.

Load references/values.md for every job: it holds the curves, durations, springs and rules to cite. Load references/recipes.md when building a common component. Load references/gestures.md for anything the user drags, flicks, swipes or can grab mid-flight.

The gate

Every animation, existing or proposed, answers these in order. The first failure ends it.

1. How often is it seen? Hundreds of times a day, or triggered from the keyboard: no animation, the state changes instantly. Tens of times a day: barely perceptible, or nothing. Occasional (dialogs, sheets, notices): standard motion. Rare or first-time (onboarding, a completed setup): the only place with room for flourish.
2. What is it for? Name one: feedback that input landed, where something came from or went, a state change made legible, bridging content that would otherwise jump, explaining how something works (onboarding and marketing only), or delight (rare moments only). "It looks nice" on something seen daily is a fail.
3. Does it help here? Numbers someone is reading, a table they are scanning, a form they are filling in: these stay still. Decoration belongs where nothing is being worked on.