Finding Missing Motion

This is a filter that happens to also be a finder. The default posture is rejection: assume the interface needs no more motion than it has, and make every candidate earn its place by surviving a four-question gate in order. An opportunity finder with a low bar is actively harmful — it produces the over-animated, sluggish interfaces the rest of this pack exists to prevent — so reject more than you propose, cap the output at five to seven for a whole app, and treat "this already has the right amount of motion" as a successful result.

The sibling is motion-audit, and the split is whether the motion exists yet: motion-audit sweeps animations that are present and wrong and returns a prioritized fix plan, while this skill only proposes motion that is absent and never returns a verdict or a plan. It also never implements — hand a surviving row to motion-audit plan <candidate> and let that skill specify it. One narrower boundary: delight decides whether a rare moment deserves extra craft at all; this skill locates the seam and names the recipe once that question is settled.

Write every proposal in the vocabulary the project already has. Before hunting, read the repo's easing and duration tokens, its motion library (motion/framer-motion, React Spring, GSAP, WAAPI, or plain CSS), and which curve family it uses — the settling one that lands on 1 or the overshooting one that passes it. A proposal naming a curve the repo does not own, or requiring a library to do what a CSS transition already does, fails its own gate and never reaches the table.

The Gate

Every candidate answers all four, in order. Record the answers — they go in the report.

1. Frequency. The frequency gate run backwards: the tiers that forbid animation also forbid proposing it.