agentsclimarketplace

Motion spec

Skill SkillMedev/skills/skills/motion-spec

The open Skill Me catalog — every hosted skill as a portable, MIT-licensed SKILL.md

Install
npx -y skills add SkillMedev/skills --skill motion-spec

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Specifies animation and motion precisely - duration, easing curve, trigger, and intent - for accurate engineer implementation. Use when handing off transitions, micro-interactions, or loading states.

SKILL.md

4.5 KB, as published. Nobody here has run it

Motion Spec

Motion that is vaguely specified gets implemented incorrectly or skipped. Every animation needs five pieces of information: what moves, when it triggers, how long it takes, what easing curve it follows, and why it exists. Provide all five.

The Five Required Fields

For every animated element, document:

  1. Element: the component or property being animated (e.g. 'modal overlay opacity', 'button background color').
  2. Trigger: the event that starts the animation (e.g. 'user clicks confirm', 'data fetch resolves', 'component mounts').
  3. Duration: in milliseconds. Do not use vague terms like 'fast' or 'subtle'.
  4. Easing: the named curve or cubic-bezier values (e.g. 'ease-out', 'cubic-bezier(0.4, 0, 0.2, 1)'). Note if the design tool curve must be converted.
  5. Intent: one sentence on why the motion exists - it guides engineers when they must adapt the spec to constraints.

Standard Duration Reference

Calibrate against these ranges; deviate only with intent:

  • Micro-interactions (button press, toggle, checkbox): 100-200ms.
  • Element enter/exit (dropdown, tooltip, popover): 200-300ms.
  • Panel or sheet transitions (side drawer, modal): 300-400ms.
  • Page-level transitions or complex orchestrations: 400-600ms.
  • Never exceed 600ms for UI feedback; reserve longer durations for deliberate narrative motion.

Easing Conventions

  • Elements entering the screen: ease-out (starts fast, decelerates into place).
  • Elements leaving the screen: ease-in (starts slow, accelerates off).
  • Elements repositioning within the screen: ease-in-out.
  • Spring or bounce effects: provide the stiffness and damping values, not just 'spring'.
  • If using a design system token (e.g. 'motion-ease-standard'), include the resolved cubic-bezier so engineers without design-tool access can verify.

Orchestration and Sequencing

When multiple elements animate together:

  • List each element in order with its offset delay (e.g. 'icon fades in at 0ms, label fades in at 60ms').
  • State whether elements overlap in time or wait for the previous to complete.
  • Describe the 'feel' goal in one phrase (e.g. 'staggered reveal, content appears to cascade down') so engineers catch drift during review.

Reduced Motion

Every motion spec must include a reduced-motion variant:

  • State which animations are removed entirely vs. replaced with an instant state change vs. reduced in duration.
  • Default: respect 'prefers-reduced-motion: reduce' by removing decorative motion and collapsing durations to 0ms for essential transitions.
  • Mark any animation that conveys information (not just decoration) - these must have a non-motion fallback.

Deliverable

Produce a motion spec table with one row per animated element containing all five required fields (element, trigger, duration in ms, easing with resolved curve values, intent), an orchestration timeline with explicit offset delays for any multi-element sequence, and a reduced-motion variant for every row.

Quality bar

  • Every animation carries all five fields - no missing durations, unnamed curves, or absent intent lines.
  • Easings follow the enter/exit/reposition conventions, or the spec states why they deviate.
  • Multi-element sequences list explicit offsets in milliseconds, not "slightly after."
  • Every row has a defined reduced-motion behavior.
  • An engineer can implement the spec without opening the design file.

Do NOT

  • Do not spec durations as adjectives ('quick', 'snappy', 'subtle') - engineers cannot implement adjectives, and each will guess a different number.
  • Do not use ease-in for entrances or linear easing for anything except continuous motion like spinners - ease-in entrances feel sluggish and linear UI motion feels mechanical.
  • Do not spec animation on layout-triggering properties (width, height, top/left) when transform and opacity achieve the same effect - layout animation drops frames on low-end devices.
  • Do not stack stagger delays until a routine UI sequence exceeds ~1 second total - orchestration that delays the user's next action stops feeling polished and starts feeling slow.
  • Do not point engineers at a design-tool prototype as the spec - playback speed and curves differ from the export; hand over the actual millisecond and bezier values.
  • Do not ship a spec without the reduced-motion variant - retrofitting it later produces inconsistent behavior across components.

Gives 0 of the 12 instructions most plan spec skills give

Counted across 1,100 of the 1,860 authors here whose files we hold, read 2026-08-06

  • ask one question at a timein 46 of 1100, across 38 files
  • Break plans into vertical slicesin 28 of 1100, across 10 files
  • Publish issues in dependency orderin 27 of 1100, across 9 files
  • Iterate until user approves the breakdownin 24 of 1100, across 6 files
  • Explore the repository to understand the codebase statein 24 of 1100, across 7 files
  • Use domain glossary vocabularyin 23 of 1100, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1100, across 5 files
  • Write failing tests before implementation codein 23 of 1100, across 18 files
  • Prefer AFK slices over HITLin 22 of 1100, across 7 files
  • ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
  • Respect existing architecture decision recordsin 20 of 1100, across 5 files
  • write a specification before writing any codein 20 of 1100, across 12 files

Said here and by no other author read

  • document five fields for every animated element
  • specify durations in milliseconds
  • provide cubic-bezier values for all easing curves
  • state intent in one sentence
  • list offset delays for multi-element sequences
  • describe the feel goal for orchestrations

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.