Menu

Individual skill

motion-language-designer

0upvotes

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.

motion-language-designer/SKILL.md

Read pinned source

Source commit b2267d9171af4f56848d82992381b20b89b44056

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Instructions only
Last checked
Nov 10, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
425
Repository last updated
Oct 20, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# 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

1. **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.
2. **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.
3. **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).
4. **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.
5. **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.
6. **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
Back to top