Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Animated UI component generator

Generates a production-ready motion spec for an animated UI component from an interaction description — covering state machine, transition timing curves, gesture mapping, performance budgets, and Rive/Lottie…

download .md

Purpose

Turn a plain-language description of a UI interaction into a complete, buildable motion specification — states, transitions, timing curves, gesture triggers, and performance constraints — so developers implement the animation exactly as intended without guessing at easing values or dropping frames on mobile.

When to Use

Invoke this skill when the user asks to:

  • Spec an animated button, toggle, tab bar, or micro-interaction
  • Design a loading, skeleton, success, or error state animation
  • Define a screen-to-screen transition or shared-element animation
  • Map a gesture (swipe, drag, pull-to-refresh) to motion behavior
  • Prepare a Rive or Lottie handoff spec for developers
  • Standardize animation timing and easing across a component library

Inputs Required

Before starting, collect:

  • Interaction description: What the user does and what should visually happen (2–4 sentences)
  • Platform target: iOS / Android / React Native / Flutter / Web
  • Implementation tech: Rive / Lottie / native (Core Animation, Compose, Reanimated) / CSS
  • Component states: Known states this component moves between (e.g., idle, pressed, loading, success)
  • Trigger type: Tap / drag / scroll / gesture / system event / time-based
  • Brand motion feel: 2–3 adjectives (e.g., snappy, playful, calm, precise)
  • Performance floor: Lowest-end device to support, if known

If tech or performance floor is missing, default to Rive for interactive state-machine components and Lottie for playback-only, and assume a mid-tier device (60fps target, degrade gracefully below).

Instructions

Step 1: Define the State Machine

List every distinct visual state the component occupies and the events that move it between them.

  • Name each state (Idle, Hover, Pressed, Active, Loading, Success, Error, Disabled)
  • For each state, describe the resting visual (position, scale, opacity, color, blur)
  • Map transitions as directed edges: From State → To State with the triggering event
  • Flag any state that can be interrupted mid-transition and what happens on interruption
  • Note whether states are exclusive or can layer (e.g., Loading + Disabled)

If Rive is the target, structure this explicitly as inputs (Boolean, Number, Trigger) driving a state machine — name the inputs a developer would wire up.

Step 2: Specify Transition Timing and Easing

For each transition edge from Step 1, define:

  • Duration: In milliseconds — keep taps under 200ms, screen transitions 250–350ms, ambient loops 800ms+
  • Easing curve: Named curve plus cubic-bezier values (e.g., easeOutExpo → cubic-bezier(0.16, 1, 0.3, 1))
  • Property choreography: Which properties animate, in what order, with what stagger
  • Spring vs. tween: Use spring physics for gesture-following and playful feels; use tween for precise, deterministic motion — specify stiffness/damping if spring

Match easing to the brand motion feel: snappy → fast-out curves; calm → symmetric ease-in-out; playful → slight overshoot/bounce.

Step 3: Map Gestures and Triggers

Connect physical input to motion response:

  • Discrete triggers (tap): Instant state change with feedback within 100ms of touch
  • Continuous gestures (drag, scroll): Motion tracks input 1:1 or with resistance — define the mapping curve and any rubber-banding
  • Threshold behaviors: At what point (velocity or distance) does the gesture commit vs. snap back
  • Haptic pairing: Where a haptic should fire and its type (light/medium/heavy impact, selection)

Step 4: Set Performance Budgets

Define constraints that keep the animation smooth on the performance floor:

  • Frame target: 60fps (16.6ms/frame budget) or 120fps for ProMotion devices
  • What runs on the compositor: Prefer transform and opacity — flag any layout, shadow, or blur animation as a cost risk with a fallback
  • Asset weight: For Rive/Lottie, cap file size and note vector complexity limits; recommend rasterizing complex static elements
  • Degradation plan: What simplifies on low-end devices (reduce particle count, disable blur, shorten durations, or fall back to a static state)
  • Reduced-motion: Define the accessibility fallback for prefers-reduced-motion — usually a cross-fade or instant state change

Step 5: Write Implementation Notes

Tech-specific handoff guidance:

  • Rive: Name the state machine, list inputs by type, note which artboard/nested artboards, and describe listener setup
  • Lottie: Frame ranges per segment, markers to expose, and dynamic property bindings (colors, text)
  • Native: The specific API (spring animator params, transition coordinator, layout animation) and property values
  • Include any edge cases: interrupt handling, rapid re-tap, offscreen pause behavior

Output Format

  • Structure: Five labeled sections plus a state-transition table
  • Length: 700–1,000 words
  • Format: Structured document with a transition table (From / To / Trigger / Duration / Easing) and bulleted spec sections
  • Sections: State Machine → Transition Timing table → Gestures & Triggers → Performance Budget → Implementation Notes
  • Tone: Precise and buildable — a developer should implement it without asking follow-up questions; specify numbers, not adjectives

Quality Checklist

Before delivering output, verify:

  • [ ] Every state has a defined resting visual and every transition has a trigger
  • [ ] All transitions specify both a duration in ms and a named easing curve with bezier/spring values
  • [ ] The transition table includes at least one interrupt or snap-back behavior for interactive components
  • [ ] A reduced-motion fallback is defined
  • [ ] A low-end-device degradation plan is included with specific simplifications
  • [ ] Implementation notes match the stated tech (Rive inputs named, or Lottie frame ranges, or native API params)

Notes

  • Rive earns its cost when the component has real state logic or gesture-following; for one-shot playback animations, Lottie is lighter to ship and easier to hand off.
  • The most common cause of janky mobile motion is animating properties that trigger layout — keep motion on transform and opacity whenever possible and call out exceptions explicitly.
  • Durations under 100ms read as instant and can feel broken; durations over 400ms on a tap feel sluggish. Anchor timing to perceived responsiveness, not visual drama.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills