Sagargupta16 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-changesparingly 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-motionguards or tone motion down; if they require accessibility-first motion, do the opposite. Ask if no policy is stated and the change is significant.