---
name: animation-review
description: Review any animation Claude made (web UI motion, iOS transitions, Remotion/HyperFrames video, SVG/CSS motion, explainer scenes) against the principles of animation before it ships. Use when an animation, transition, motion spec or video scene was just built or changed, when the user says "review the animation", "it feels too fast/janky", "motion QA", or before shipping any user-facing motion on a product, a site or a demo. Produces a pass/fail table that cites a frame or timestamp per item, one revision pass, and a re-render.
---

# Animation Review — the principles of animation as a pass/fail gate

> **Why this exists.** Claude-made animation fails in the same ways: too fast, linear easing, everything
> moving at once, nothing settling. Reviewing code does not catch this. Reviewing FRAMES does.
> Source: the 12 principles (Thomas & Johnston, *The Illusion of Life*, 1981); John Lasseter,
> "Principles of Traditional Animation Applied to 3D Computer Animation", SIGGRAPH 1987
> (https://www.evl.uic.edu/aej/527/papers/lasseter.pdf).

## Inputs
- The animation: a URL/route, an iOS screen, a Remotion composition, or a rendered video file.
- The project's motion spec if one exists. Read it first; it overrides the defaults below.
  Examples: a `docs/design/interaction-motion.md` file; an executive-audience product that rules out
  playful motion; a decisions-ledger entry that rules out a video renderer.
- The brand stance on exaggeration (default: N/A for product and executive-facing UI).

## Method
1. **Capture frames, not code.** Pick the capture route that fits:
   - Web: record with Playwright or chrome-devtools (screenshots at fixed offsets, e.g. every 50 ms
     through the motion), or a screen recording.
   - iOS simulator: `xcrun simctl io booted recordVideo motion.mov`, then extract frames.
   - Remotion: `npx remotion still <comp> --frame=<n>` at the key frames.
   - Any video: `ffmpeg -i in.mp4 -vf "fps=10,scale=320:-1,tile=6x4" sheet.png` for a contact sheet.
2. **Run the checklist** below on the frames. Each row is PASS / FAIL / N/A and cites a frame number or
   timestamp. No citation means the row was not checked.
3. **Revise once.** Fix every FAIL in one pass. Change timing and easing values, not the concept.
4. **Re-render and re-check** only the rows that failed. Report the before/after values.

## Checklist (defaults; a project motion spec overrides)
| # | Principle | Pass when |
|---|---|---|
| 1 | Timing | UI moves take 150–400 ms. In video, each new idea stays on screen at least 0.6 s. A key reveal has a 300–600 ms hold before it. When in doubt, slow down. |
| 2 | Slow in, slow out | No linear easing except continuous loops. Default expo-out or a tuned spring. |
| 3 | Anticipation | A large move has a small counter-move or cue before it (press, lift, dim). |
| 4 | Follow-through and overlap | Children settle 30–50 ms after parents (stagger). Nothing stops dead. |
| 5 | Arcs | Moving objects travel on curves unless the motion is meant to be mechanical. |
| 6 | Staging | One focal element per beat. Everything else holds still or dims. One motion idea per screen. |
| 7 | Squash, stretch, exaggeration | Used only where the brand allows. Otherwise mark N/A by brand. |
| 8 | Secondary action | Present only if it does not compete with the focal element. |
| 9 | Appeal and legibility | Text stays readable for its full duration (allow about 0.3 s per word). Contrast meets WCAG AA. |
| 10 | Pose to pose | Keyframes are defined first; interpolation between them is checked on frames. |
| 11 | Exit and performance | Exit takes about 70% of the enter time. Only transform and opacity animate. A reduced-motion fallback exists and was checked. |
| 12 | Solid form | Shapes keep consistent size, weight and perspective across frames (no wobble, no jumping baseline). |

## Output
1. The checklist table with PASS/FAIL/N/A and a frame or timestamp per row.
2. The changes made in the revision pass (old value → new value).
3. A ≤6-line summary: what failed, what changed, what still needs a human eye.

## Rules
- Review rendered frames. A code-only review does not count.
- The project motion spec wins over these defaults. Quote the spec line when it does.
- Never add an animation library to fix a review finding. Tune the existing values.
- Respect `prefers-reduced-motion` on every surface. Its absence is a FAIL.

## Common rationalizations
| Rationalization | Reality |
|---|---|
| "It looks fine in my head from the code." | Capture frames. Timing problems are invisible in code. |
| "Faster feels snappier." | Fast motion that the eye cannot follow reads as a glitch. Slow down first, then trim. |
| "Linear is fine for this." | Only for loops. Everything else eases. |
| "Reduced motion is an edge case." | It is an accessibility requirement. No fallback is a FAIL. |

## Red flags (stop and re-check)
- A checklist row has no frame or timestamp.
- Two or more elements start moving on the same frame with equal emphasis.
- Any duration under 100 ms on a visible move, or a video idea on screen under 0.6 s.
- Width, height, top or left is animated instead of transform.