Define a product's motion design language -- duration and easing scales, choreography rules, and signature moves -- and export it as tokens plus ready-to-use Framer Motion variants and CSS. The difference between animations and a motion system: everything moves like it belongs to the same product.
SkillScore35Maintained
Automatic
◆Frontend / UI pack
Last verified 8/24/2026
What it changes
Passed 8 of 23 test cases with the skill, and 3 of 23 without it.
Without skill13%
With skill35%
Checks it passed that the model alone missed
The system defines between 3 and 5 named signature moves.
The choreography rules enforce a maximum of one hero motion per view.
The animation export includes a prefers-reduced-motion media query guard.
and 6 more in the full report
7 fixed1 passed either way13 still failing2 broke
Pass-rate lift
+22 pp
Tokens
+26%
Agent turns
0%
Response time
+5%
Model gemini-3.6-flashMeasured 8/24/2026v18 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
Our web application has accumulated dozens of ad-hoc transitions and random inline animation props across different components. Can you audit our current codebase setup, establish a standardized motion scale, and export the drop-in CSS/TS files along with a retrofit guide to migrate off-system transitions onto the new tokens?
What was checked, without and with the skill
Checked
Without skill
With skill
The output produces motion-tokens.json, motion.ts, motion.css, and MOTION.md as key deliverables.
Missed
Passed
The system defines between 3 and 5 named signature moves.
Missed
Passed
The choreography rules configure exit animations to be faster than entrance animations.
Missed
Passed
case-02 · gemini-3.6-flash · 8/24/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md28 linessingle file
Motion Language Designer
Design motion the way type and color get designed: as a system with a scale, roles, and rules -- not per-component improvisation. Output is a motion spec plus drop-in implementation (Framer Motion variants, CSS custom properties and keyframes) so the system is enforceable, not aspirational.
Workflow
Read the brand. From the existing product (or its design tokens and a description of the personality): is this product calm, snappy, playful, austere? Audit any existing animations -- inventory every duration, easing, and effect currently in the codebase. The spread of that inventory (14 different durations is typical) is the motivation slide.
Define the scale. Duration tokens (instant ~100ms for state feedback, fast ~180-220ms for micro-interactions, base ~300ms for reveals, slow ~500ms+ for scene changes) and an easing vocabulary (standard, decelerate for entrances, accelerate for exits, plus at most ONE signature spring/overshoot -- the personality lives here). Calibrate values to the brand read from step 1, not generic defaults.
Write the choreography rules. The part most systems skip: what animates and what never does; enter/exit asymmetry (exits faster than entrances); stagger rules (children cascade at 30-60ms, capped so long lists do not take seconds); hierarchy (one hero motion per view, everything else supports); distance rules (elements travel short distances -- 8-24px -- not across the screen); and the reduced-motion contract (every animation has a prefers-reduced-motion behavior: fade or nothing).
Name the signature moves. 3-5 named, reusable compositions ("card-lift", "panel-reveal", "count-up") that recur across the product and make it recognizable. Each gets a spec: trigger, properties animated, duration/easing tokens used, and when NOT to use it.
Export.motion-tokens.json (durations, easings, distances), motion.css (custom properties + keyframes + reduced-motion guards), motion.ts (Framer Motion variants for each signature move, referencing the tokens), and MOTION.md -- the spec a new developer reads before animating anything.
Retrofit pass (optional). Map the step-1 inventory onto the new system: which existing animations snap to which tokens, which are off-system and need changes, which should be deleted (motion that communicates nothing).
Rules
Everything animates transform and opacity; nothing animates layout properties (width, height, top) without an explicit exception logged in the spec.
One signature easing maximum. A product where some things bounce and other things glide has two personalities.
Motion communicates or it goes: entrances orient, feedback confirms, transitions preserve context. "It looked cool" is not a role.
Durations come from the scale only. A 270ms one-off is drift, same as a rogue hex.
The reduced-motion contract is not optional and not an afterthought -- it ships in the same file as every animation.
Fast beats slow when unsure: users read 200ms as responsive and 500ms as sluggish long before they read either as beautiful.
Quick Commands
"Design a motion system for this product" -- full workflow
"Audit my animations" -- step 1 inventory only
"Just the tokens and variants" -- steps 2, 5
"Retrofit my components" -- step 6 against an existing system