Skip to content
Report library
Purpose / Development

Review Animations Skill Security Audit

What the author says it does (original text)

Reviews animation and motion code against a high craft bar derived from Emil Kowalski's design engineering philosophy. Default to flagging; approval is earned.

Independent security check

Security risks found

Files checked
2
Risks found
2
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.Risks found: 2
Medium risk

Absolute rules can force blocking decisions without product context

Source references: 4
What we found

The Skill defaults to finding faults and makes keyboard-triggered motion, UI durations over 300ms, and several implementation choices automatic blocking conditions. It does not require checking product requirements, measured performance, actual frequency, or user research first, so verdicts may follow presets rather than project evidence.

Why this matters

If its verdict becomes a merge gate, legitimate brand motion, longer explanatory animation, or keyboard interactions that communicate state could be removed or prevented from shipping.

The Skill adopts a “default to flagging” posture, makes every listed violation a finding, and mandates Block for keyboard/high-frequency motion, `scale(0)`, UI `ease-in`, and similar cases. Although duration can be justified and frequency is considered, the procedure does not explicitly require verifying actual usage frequency, product goals, or user testing first. A user could therefore reject reasonable design based on presets. The user can ask the author to require project context or measured evidence for blocking decisions and permit documented exceptions.

SKILL.md:13In the instructionsOpen original file
You are a senior design engineer with a brutal eye for craft. Your bias is toward **motion that feels right**, not motion that merely runs. A transition that "works" but feels sluggish, lands from the wrong origin, fires too often, or drops frames is a regression, not a pass. Default to flagging. Approval is earned, not assumed.
Show 3 other places
SKILL.md:25In the instructionsOpen original file
2. **Frequency-appropriate.** Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get **no** animation. Tens/day gets reduced motion. Occasional gets standard. Rare/first-time can have delight.3. **Responsive easing.** Entering/exiting elements use `ease-out` or a strong custom curve. `ease-in` on UI is a block — it delays the moment the user watches most. Built-in CSS easings are too weak; expect custom cubic-beziers.4. **Sub-300ms UI.** UI animations stay under 300ms; anything slower on a UI element needs justification or it's a finding. Per-element budgets live in [STANDARDS.md](STANDARDS.md).
SKILL.md:104In the instructionsOpen original file
- **Block** — any feel-breaking regression, animation on a keyboard/high-frequency action, `scale(0)`/`ease-in` on UI, or a non-GPU animation with an easy GPU fix.- **Approve** — no feel-breaking regressions, no obvious motion that should be deleted, durations and easing within bounds, interruptibility handled where needed, reduced-motion respected.
SKILL.md:21In the instructionsOpen original file
Every animation in the diff is measured against these. A violation is a finding.1. **Justified motion.** Every animation must answer "why does this animate?" — spatial consistency, state indication, feedback, explanation, or preventing a jarring change. "It looks cool" on a frequently-seen element is a block.2. **Frequency-appropriate.** Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get **no** animation. Tens/day gets reduced motion. Occasional gets standard. Rare/first-time can have delight.
Medium risk

Overbroad and conflicting performance claims may drive unjustified rewrites

Source references: 4
What we found

The reference says only transform and opacity should be animated and that Framer Motion x/y/scale are categorically not hardware accelerated, while also recommending animated clip-path. It permits modals and drawers up to 500ms but separately says all UI must stay below 300ms. These absolutes are not conditioned on browser, device, or profiling data.

Why this matters

Users may rewrite motion for a performance problem that is not present, introducing regressions and maintenance cost. The same implementation may also receive opposite verdicts depending on which rule is selected.

The reference contains decision-relevant contradictions: its table permits 500ms for modals/drawers, immediately followed by a rule that UI animation must remain below 300ms. It says to animate “only” transform/opacity while elsewhere presenting clip-path as an animation tool and WAAPI example. It also makes an unconditional performance claim about Framer Motion shorthands without version, browser, or measurement conditions. Following this literally could cause unnecessary rewrites. Users can ask for explicit exception precedence and require profiling in the target environment before performance findings.

STANDARDS.md:41In the instructionsOpen original file
| Element | Duration || --- | --- || Button press feedback | 100–160ms || Tooltips, small popovers | 125–200ms || Dropdowns, selects | 150–250ms || Modals, drawers | 200–500ms || Marketing / explanatory | Can be longer |**Rule: UI animations stay under 300ms.** A 180ms dropdown feels more responsive than a 400ms one. Faster spinners make load feel faster (same actual time). Instant tooltips after the first (skip delay + animation) make a toolbar feel faster.
Show 3 other places
STANDARDS.md:112In the instructionsOpen original file
- **Only animate `transform` and `opacity`** — they skip layout/paint and run on the GPU. `padding`/`margin`/`height`/`width`/`top`/`left` trigger all three rendering steps.- **Don't drive child transforms via a CSS variable on the parent** — it recalcs styles for all children. Set `transform` directly on the element.  ```js  element.style.setProperty('--swipe-amount', `${d}px`); // bad: recalc on all children  element.style.transform = `translateY(${d}px)`;        // good: only this element  ```- **Framer Motion shorthands are NOT hardware-accelerated.** `x`/`y`/`scale` run on the main thread via rAF and drop frames under load. Use the full transform string:  ```jsx  <motion.div animate={{ x: 100 }} />                          // drops frames under load  <motion.div animate={{ transform: "translateX(100px)" }} />  // hardware accelerated  ```- **CSS animations beat JS under load** — they run off the main thread; rAF-based animations stutter while the browser loads/scripts/paints. Use CSS for predetermined motion, JS for dynamic/interruptible.- **WAAPI** gives JS control with CSS performance (hardware-accelerated, interruptible, no library):
STANDARDS.md:124In the instructionsOpen original file
- **CSS animations beat JS under load** — they run off the main thread; rAF-based animations stutter while the browser loads/scripts/paints. Use CSS for predetermined motion, JS for dynamic/interruptible.- **WAAPI** gives JS control with CSS performance (hardware-accelerated, interruptible, no library):  ```js  element.animate([{ clipPath: 'inset(0 0 100% 0)' }, { clipPath: 'inset(0 0 0 0)' }],    { duration: 1000, fill: 'forwards', easing: 'cubic-bezier(0.77, 0, 0.175, 1)' });  ```
STANDARDS.md:135In the instructionsOpen original file
- **3D**: `rotateX/Y` + `transform-style: preserve-3d` for depth/orbit/flip without JS.- **`clip-path: inset(t r b l)`** is a powerful animation tool: each value eats in from that side. Uses: reveal-on-scroll (`inset(0 0 100% 0)` → `inset(0 0 0 0)`), hold-to-delete overlay, seamless tab color transitions (duplicate + clip the active copy), comparison sliders.
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

6 instruction sections

This Skill only reviews animation and motion code, applies ten rules to every animation in a diff, and explicitly declines general code review.

View source
SKILL.md:9In the instructionsOpen original file
A specialized review skill. It does ONE thing: review animation and motion code against a high craft bar. It does not write features, fix unrelated bugs, or review non-motion code. If asked to review general code, decline and point to a general review skill.
SKILL.md:21In the instructionsOpen original file
Every animation in the diff is measured against these. A violation is a finding.

Its required output is a per-issue change table followed by an explicit Block/Approve decision with file-and-line citations.

View source
SKILL.md:82In the instructionsOpen original file
A single markdown table. One row per issue. Never a "Before:/After:" list.
SKILL.md:102In the instructionsOpen original file
Close with an explicit decision:- **Block** — any feel-breaking regression, animation on a keyboard/high-frequency action, `scale(0)`/`ease-in` on UI, or a non-GPU animation with an easy GPU fix.- **Approve** — no feel-breaking regressions, no obvious motion that should be deleted, durations and easing within bounds, interruptibility handled where needed, reduced-motion respected.
SKILL.md:107In the instructionsOpen original file
Be specific and cite `file:line`. When a value is needed (a curve, a duration, a spring config), pull the exact one from [STANDARDS.md](STANDARDS.md) rather than approximating.

The supplied files contain no installation steps, scripts, commands, credential handling, network requests, or file-writing instructions; the visible behavior primarily directs the model's review judgments.

View source
SKILL.md:64In the instructionsOpen original file
When proposing fixes, prefer earlier moves over later ones:1. **Delete the animation** (high-frequency / no purpose / keyboard-triggered).2. **Reduce it** — shorter duration, smaller transform, fewer animated properties.3. **Fix the easing** — swap `ease-in`→`ease-out`/custom curve; use a strong cubic-bezier.4. **Fix the origin/physicality** — correct `transform-origin`; replace `scale(0)` with `scale(0.95)`+opacity.5. **Make it interruptible** — keyframes → transitions, or a spring for gesture-driven motion.6. **Move it to the GPU** — layout props → `transform`/`opacity`; shorthand → full `transform` string; WAAPI for programmatic CSS.7. **Asymmetric timing** — slow the deliberate phase, snap the response.8. **Polish** — blur to mask crossfades, stagger for groups, `@starting-style` for entry, spring for "alive" elements.9. **Accessibility & cohesion** — add reduced-motion + hover gating; tune to match the component's personality.
Start here · InstructionsSKILL.md
review-animations
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.

File reference map

References: 1
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records2 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • STANDARDS.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • STANDARDS.mdSupporting file

Operations mentioned in code and instructions

Connect to websites
STANDARDS.md:37In the instructionsOpen original file
Find curves at [easing.dev](https://easing.dev/) or [easings.co](https://easings.co/) — don't hand-roll from scratch.
Lines read
301
File checksum (to compare versions)
5168c1172cd1dae8283e4e47682b04bec89015198b2f9d108a692022d0fb2229