motion-effect-system

Define motion system contracts with timing, easing, and reduced-motion fallbacks.

Updated Apr 27, 2026
One-click install
npx skills add https://github.com/vTRKA/supervibe --skill motion-effect-system
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: motion-effect-system
Source: https://github.com/vTRKA/supervibe/tree/main/skills/motion-effect-system
Command: npx skills add https://github.com/vTRKA/supervibe --skill motion-effect-system

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Motion requirements often stay informal, causing accessibility gaps, inconsistent easing/timing, missing reduced-motion parity, and unprovable runtime claims during design and handoff.

Core Features & Use Cases

  • Motion system contract: Defines named timing tiers, easing tokens, choreography rules, and approval boundaries for when motion is allowed or must be removed.
  • Accessible fallback planning: Requires no-motion equivalents and reduced-motion handling tied to evidence rather than taste.
  • Verification-ready output: Enforces anti-AI-slop evidence, gate IDs, and an output report contract that separates static review from runtime proof.
  • Specialist routing: Delegates actual playback/implementation to runtime-focused skills (e.g., Lottie/Rive, WebGL/Canvas, generated video) after the system contract is set.

Quick Start

Use motion-effect-system to define a token-governed animation recipe and its reduced-motion/no-motion fallback before routing implementation to runtime specialists for a specific UI state or handoff artifact.

Frequently Asked Questions about motion-effect-system

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create an accessible motion design system with reduced-motion fallbacks?▼

An accessible motion design system requires defining named timing tiers, easing tokens, and choreography rules while enforcing reduced-motion and no-motion equivalents. This creates a verifiable design contract that separates static review from required runtime proof.

What is a motion system contract for design handoff?▼

A motion system contract for design handoff is a defined set of named timing tiers, easing tokens, and approval boundaries dictating when motion is allowed or must be removed. It enforces anti-slop evidence and gate IDs for verifiable runtime claims.

How do I enforce reduced-motion accessibility in animation tokens?▼

You enforce reduced-motion accessibility in animation tokens by requiring no-motion equivalents and reduced-motion handling tied to evidence rather than taste. The system separates static approval from required browser runtime proof to prevent accessibility gaps.

Does this motion design approach handle state-transition choreography for app surfaces?▼

Yes, this motion design approach handles state-transition choreography across interaction, route, media, and runtime boundaries for app surfaces. It defines choreography rules and delegates actual playback implementation to runtime-focused specialists.

What is the best way to document animation tokens for developer handoff?▼

The best way to document animation tokens for handoff is generating an output report that separates static approval from required browser runtime proof. This enforces anti-AI-slop evidence and gate IDs to verify all motion claims.

When should I not use a system-level motion contract for prototypes?▼

You should not use a system-level motion contract for prototypes if you need actual playback or implementation, as this approach solely defines the token-governed animation recipe. It routes runtime execution to specialized skills after setting the contract.