motion

Motion

One skill, three modes. Pick by intent; load only the matching reference file.

Mode	When	Reference
audit	Review existing animation code for quality -- outputs file:line findings against the 12 principles	references/audit-12-principles.md
add	Enhance a feature with new animations, micro-interactions, motion design	references/add-motion.md
fix	Animations stutter, transitions jank, perf review of CSS/JS motion	references/fix-performance.md

Invocation: /motion audit <files>, /motion add [target], /motion fix [file]. Bare /motion fix applies the performance constraints to all UI animation work in this conversation. If no mode is given, infer from the ask (review/check -> audit; add/enhance -> add; jank/slow/stutter -> fix).

Mode boundaries (the numbers differ by design)

Each mode's numeric rules apply only within that mode -- they intentionally disagree:

• Stagger: audit enforces <=50ms per item on existing code; add recommends 100-150ms delays for page-load choreography. When adding motion that must later pass an audit, prefer the audit cap.
• Feedback duration: audit fails user-initiated animations over 300ms; add allows 300-500ms for layout changes. Audit numbers win for interaction feedback.
• Springs vs easing: audit prescribes springs for overshoot-and-settle; add bans bounce/elastic easing curves. Both are right: springs yes, bounce/elastic cubic-beziers no.

Hard rules (all modes)

• transform + opacity only for motion; never animate layout properties (width, height, top, left)
• will-change sparingly and temporarily, never permanent
• Never migrate or rewrite animation libraries unless explicitly requested
• Respect the project's stated motion policy: if the user or project rules say animations should stay bold and visible, do not add prefers-reduced-motion guards or tone motion down; if they require accessibility-first motion, do the opposite. Ask if no policy is stated and the change is significant.