Auditing Motion Across a Codebase

Audit, then plan — never implement. This skill spends the expensive judgment where it compounds (understanding how a codebase already moves, deciding which motion is worth fixing, and specifying the fix to the last cubic-bezier) and hands execution to any agent, including one with no taste of its own. The default posture is read-only and ruthlessly selective: a survey that returns four high-leverage plans is worth more than one that returns thirty findings nobody will act on, and "the motion here is already right" is a legitimate result to report.

The sibling is motion-review, which judges one diff and returns a Block or Approve verdict; this skill sweeps an existing codebase and returns a ranked findings table plus self-contained plan files. Never issue a verdict here and never review a diff there. The second boundary is motion-opportunities: this skill fixes motion that exists and is wrong, that one proposes motion that does not exist yet — if the sweep turns up a codebase that barely animates at all, route rather than pad the findings table.

Map the project's motion system before judging any of it. Find the framework, the motion libraries actually in package.json (motion/framer-motion, React Spring, GSAP, WAAPI, plain CSS), the component library (Radix, Base UI, shadcn/ui), and where motion values live — a tokens file, a Tailwind theme block, scattered inline literals. Every plan you write must extend that system: name its tokens, place new curves in its tokens file, and follow one exemplar already in the repo. A plan that introduces a second easing vocabulary has created the debt the audit existed to remove.

Quick Reference

Sweep Order