Quick Answer: To animate SVG illustrations so they feel alive, you need one shared clock, parts that rotate around their real pivots, small motion amplitudes, and smooth curves through key poses. The open-source rossark-motion-skill packages these rules for Claude Code, with engine templates for React Native and SwiftUI that target 60 fps.
If you want to animate SVG illustrations, the hard part isn't making a drawing move. Any tween can do that. The hard part is making it breathe, look around, blink, and shift its weight without freezing or jumping. Most AI-generated animation fails here. The face teleports between expressions, the body stops dead at each pose, and every element bounces in lockstep. The rossark-motion-skill on GitHub is an attempt to fix this at the instruction level, so your coding agent stops making those mistakes before they reach your screen.
Why Most Agent-Made Animation Looks Like a Slideshow
Here's the core problem. When an agent animates a character from pose A to pose B, it usually writes a separate eased tween for each transition. Each tween starts with a slow ease-in and ends with a slow ease-out. Chain five of those together and the character accelerates, stops, accelerates, and stops again at every pose. Your eye reads that stop as mechanical.
The fix sounds backwards: you don't add more easing. You stop treating poses as endpoints and treat them as waypoints on one continuous curve. The skill's flow function does this, passing smoothly through key poses so velocity carries from one into the next. The same reasoning applies to blinks. A blink that lasts a single frame at 60 fps reads as a flicker, not an eyelid.
Four failure modes show up repeatedly:
- Teleporting expressions. Swapping one drawing for another with no interpolation.
- Dead stops. Per-pose easing that halts motion at every key frame.
- Lockstep motion. Every element on the same timing, which looks like a machine.
- Visible seams. A thin line where two shapes meet during a transform.
The repo lists these as pitfalls, and it treats each one as a rule the agent must check.
That said, not every stop is a bug. A mechanical object such as a lever or a door should stop cleanly. The skill's guidance is about organic subjects, and you should decide which of your subjects are which before you ask for motion.
One Clock, Real Pivots, and Follow-Through
Three structural rules do most of the work. They're simple to state and easy to violate.
- Use one clock for the whole scene. Every part reads time from the same source. Separate timers drift apart and make a scene feel like several animations stacked on top of each other.
- Rotate parts around their real pivots. A forearm must rotate around the elbow, not the centre of its bounding box. Get the pivot wrong and the limb appears to slide rather than swing.
- Let trailing parts follow a beat later. Hair, tails, and the head should lag behind the body. This is follow-through, and it's what makes a motion feel physical.
Here's where most people go wrong with the second rule. SVG coordinates are often exported with the origin at the top-left of the artboard, so a rotation applied to a path rotates it around the wrong point by default. Before you write any rotation, locate the joint in the SVG's own coordinate space and set the pivot there. It takes five minutes and saves hours of debugging.
For the third rule, a common rule of thumb is to delay secondary parts by a few frames behind the primary motion. At 60 fps, that's roughly 30 to 60 milliseconds. The skill's demos use this kind of lag: in one scene, a chef's eyes track a falling pancake, and his head follows a beat later.
This next part matters more than it looks. Follow-through is the difference between "a part moves" and "a body moves," and it's the most common thing agents skip.
Measure the Motion Before You Copy It
Here's a counter-intuitive finding from the repo. When you have a reference video, the motion that makes it feel alive is often too small to see. A two-percent jiggle in a shoulder, a slight float, or a sway that lasts a few frames can be the difference between lifeless and convincing. Your eye registers the overall effect but not the mechanism.
The skill addresses this with track_edges.py, which measures a subject's edges frame by frame. It catches motion that a casual viewing misses. The companion tools are sheet.sh, which produces contact sheets at the video's full frame rate, and sample_colors.py, which reads exact colours from a frame so your recreation matches the palette.
Be careful, though. Edge tracking depends on clean footage. Heavy compression, motion blur, and low contrast can produce false edges, and you may end up "matching" noise. Check the measured curve against the contact sheet by eye before you trust it. A measurement is evidence, not a verdict.
Live Faces and Idle Life That Never Stops
Faces are where drawn characters most often fail. A face that only animates when triggered looks dead between triggers. The repo's answer is idle life: small breathing, occasional glances, and blinks at irregular intervals that never fully stop.
The skill ships liveFace.tsx for React Native and LiveFace.swift for SwiftUI. You supply the eye and mouth geometry and the colours, and the component handles gliding, blinking, and smiling. The key is that blinks are timed as real blinks. A natural blink closes and reopens within roughly 100 to 150 milliseconds, which is a practical benchmark from animation practice rather than a formal standard. Anything much shorter reads as a glitch.
Irregular timing matters as much as duration. If blinks fire at exact intervals, the character looks like a button on a timer. The skill uses seeded randomness for this, so the variation is varied but reproducible across renders. That's the reason the demo loops are stable from one render to the next.
Most guides skip this part: idle motion has to be quiet. If breathing or glancing is too large, the character looks anxious. Keep amplitudes small and let the strong curves carry the expressive moments.
Choosing Between Tweens, Springs, and Key-Pose Flow
Not every motion needs the same technique. The table below summarises the trade-offs from the repo's recipes and pitfalls.
| Technique | Best for | Main risk |
|---|---|---|
| Per-pose eased tween | Simple state toggles, UI elements | Dead stop at every pose, looks mechanical in characters |
| Spring physics | Hovering, falling, squash-and-stretch | Overshoot can look bouncy or cartoonish if overused |
Key-pose flow (flow) | Full-body acting, multi-pose sequences | Requires authoring more key poses up front |
Seeded randomness (seeded) | Sparkles, rain, drops, idle variation | Repeats identically if the seed is reused across elements |
Here's the trade-off that matters most. Springs are excellent for falling and landing, because gravity and squash map naturally onto them. But a character built entirely from springs can look like a set of bouncing balls. Key-pose flow gives you control over the whole body's path, at the cost of more setup. For a character that has to act, flow is usually the right default, with springs reserved for secondary physics like a hat wobbling after a landing.
Where the Skill Stops: Limits and Caveats
The skill is opinionated, and it's worth knowing where those opinions end.
- It assumes you have layered SVG art. Flat, single-path illustrations can't rotate limbs or blink eyes without being split into parts first. That's real manual work, and the skill doesn't do it for you.
- Interface motion follows specific rules. For motion in apps, the repo follows Emil Kowalski's animation principles and Benji Taylor's Family values. If your team has a different house style, expect to adjust the defaults.
- Output depends on your project notes. The repo includes a
MOTION.mdfile that you fill in with your code locations, rules, and what your art can't do. Without it, the agent is working blind. - Rendering has platform requirements. The demos render offline through a Swift toolchain targeting macOS 14 or later, then encode with ffmpeg. You'll need that setup to reproduce the demo videos.
- Performance on older devices is a question. The repo claims 60 fps, and the demos are built on the templates. I haven't profiled them on low-end hardware, so test on your target devices before you promise smooth motion to users.
The repo had about 362 stars when I reviewed it, which is a modest but real signal of community interest, not a substitute for your own testing.
Setting It Up in Your Project
Getting started takes a few steps:
- Install the skill with
npx skills@latest add rossark0/rossark-motion-skill. - Copy
MOTION.mdnext to your artwork and fill in Part 2: code locations, your rules, and your art's limits. - Ask your agent to animate one character, starting with the blink and the breath, before attempting full-body acting.
- Render a contact sheet with
sheet.shand compare it against your reference frame by frame.
Start small. One eye blinking convincingly teaches you more than a full scene built too fast.
Frequently Asked Questions
What is the rossark motion skill?
The rossark-motion-skill is an open-source Claude Code skill for animating drawn art. It gives the agent principles and templates for SVG characters, faces, and scenes, with engine code for React Native and SwiftUI that targets 60 fps. It's MIT licensed and installs with npx skills@latest add.
How do I animate SVG illustrations in React Native?
Split your SVG into named layers, set rotation pivots at the real joints, and drive every part from one shared clock. Use the skill's key-pose flow for body motion and its live-face component for eyes and mouths. Keep motion amplitudes small, and add a short follow-through delay for trailing parts.
Why do animations look robotic?
Robotic motion usually comes from per-pose easing, where each transition starts and stops, and from lockstep timing where every element moves together. Blinks that are too short also read as glitches. Smoothing the path through key poses and staggering secondary parts fixes most of it.
Can I use this with SwiftUI?
Yes. The repo includes Motion.swift and LiveFace.swift as SwiftUI counterparts to the React Native files. The demos are rendered with a Swift toolchain targeting macOS 14 or later, so you'll need that environment to reproduce the offline renders.
Animating SVG illustrations well comes down to one clock, real pivots, follow-through, and smooth paths through key poses. The rossark-motion-skill packages those rules so your agent applies them by default, and its contact-sheet and edge-tracking tools let you check the result against a reference. Try it on a single blink this week, and note how much the face changes once the eyelid takes 120 milliseconds instead of one frame. Then read our guide to Claude Code skills for frontend work to see how other skills fit into the same workflow, or pair this with our notes on React Native animation performance before you ship.