$npx -y skills add jaaaaaaaaaaack/custom-skills --skill animation-reviewReview web animations by recording the browser and sending video to Gemini for frame-level analysis
| 1 | # Animation Review |
| 2 | |
| 3 | Review animations and interactions by recording the browser and sending the video to Gemini for structured analysis. |
| 4 | |
| 5 | ## Prerequisites |
| 6 | |
| 7 | - `ffmpeg` installed (`brew install ffmpeg`) |
| 8 | - `playwright` Python package with Chromium (`pip install playwright && playwright install chromium`) |
| 9 | - `google-genai` Python package (`pip install google-genai`) |
| 10 | - `GEMINI_API_KEY` environment variable set |
| 11 | - For manual recording only: macOS Screen Recording permission granted to terminal app |
| 12 | |
| 13 | ## How Gemini fits in |
| 14 | |
| 15 | Gemini is the **eyes** — it watches the recording and describes what it sees with precision. You are the **hands** — you translate those observations into code changes with full codebase context. |
| 16 | |
| 17 | **Treat all Gemini analysis as observational evidence, not authoritative diagnosis.** Gemini cannot see the code. When it suggests root causes or implementation fixes, treat these as hypotheses from an external observer who can see the symptoms but not the source. Its frame-level descriptions of *what happens visually* are reliable. Its theories about *why* are informed guesses that you should verify against the actual code. |
| 18 | |
| 19 | This applies across all modes, but especially to `diagnose` (where Gemini hypothesizes about bugs) and `inspire` (where Gemini decomposes effects without knowing your tech stack). |
| 20 | |
| 21 | ### Interpreting timestamps and durations |
| 22 | |
| 23 | Gemini can only observe what's in the sampled frames. Its temporal precision depends on the analysis FPS: |
| 24 | |
| 25 | | Mode | FPS | Frame interval | What this means | |
| 26 | |------|-----|---------------|-----------------| |
| 27 | | **check** | 5 | 200ms | A "300ms animation" could be anywhere from 200-400ms (1-2 frames). Timestamps are ±200ms. Good enough for "does it happen" but not for timing accuracy. | |
| 28 | | **review** | 12 | 83ms | A "300ms animation" is ~3-4 frames. Easing character is visible. Durations are accurate within ~80ms — enough to judge "too fast" vs "too slow". | |
| 29 | | **diagnose/inspire** | 24 | 42ms | A "300ms animation" is ~7 frames. Easing curves, stagger offsets, and glitch moments are precisely observable. Durations are accurate within ~40ms. | |
| 30 | |
| 31 | When Gemini reports a duration like "~400ms with ease-out", consider the mode's precision. At 5fps that could really be 200-600ms. At 24fps it's likely 360-440ms. The system prompt tells Gemini to report in frame counts alongside milliseconds so you can judge precision yourself. |
| 32 | |
| 33 | If you're debugging a timing issue and Gemini's temporal precision isn't sufficient, re-run at a higher mode. A `check` that reveals "something's off with the timing" can be followed up with a `diagnose` for frame-precise detail. You can also escalate just a specific time range — see "Escalating a region" below. |
| 34 | |
| 35 | ## Workflow |
| 36 | |
| 37 | ### 1. Determine source and mode |
| 38 | |
| 39 | There are two entry points — figure out which applies: |
| 40 | |
| 41 | **User provides a video file.** The user has a screen recording (.mov, .mp4, .webm) — either of their own UI or a reference they want to recreate. Skip straight to step 3 (Analyze). No recording step needed. User-provided videos are typically 30-60fps, which is more than enough for any analysis mode — Gemini downsamples to the mode's FPS automatically. |
| 42 | |
| 43 | **Agent captures from the browser.** The animation is running in a local dev server and needs to be recorded. Proceed to step 2 (Record), then step 3 (Analyze). |
| 44 | |
| 45 | Choose the analysis mode based on what question you're trying to answer: |
| 46 | |
| 47 | | Mode | FPS | Model | Question | When to use | |
| 48 | |------|-----|-------|----------|-------------| |
| 49 | | **check** | 5 | Flash | "Does it work?" | First pass — verify the animation fires, completes, and doesn't visually break. Early development, after wiring up a new animation, smoke testing. | |
| 50 | | **review** | 12 | Flash | "How does it feel?" | Design and polish — evaluate easing, timing, choreography, and overall quality. Use when the animation works but needs refinement, or for design review before shipping. | |
| 51 | | **diagnose** | 24 | Pro | "What's going wrong?" | Bug investigation — the animation has a specific visual problem (jump, stutter, misalignment, timing glitch). Need frame-precise evidence to locate the root cause in code. | |
| 52 | | **inspire** | 24 | Pro | "What's happening here?" | Reference analysis — the user has a video showing a desired effect and wants a technical decomposition to guide implementation. | |
| 53 | |
| 54 | **Decision guide for agents:** |
| 55 | |
| 56 | - User says "check if this works" / "does the animation play" / just implemented something new → **check** |
| 57 | - User says "how does this look" / "review the animation" / "is the timing right" / design feedback → **review** |
| 58 | - User says "there's a bug" / "it jumps" / "something's wrong with" / describes a specific visual issue → **diagnose** |
| 59 | - User provides a video of someone else's UI / "I want it to look like this" / "recreate this effect" → **inspire** |
| 60 | - For **inspire**: if the user hasn' |