name: animate-css-optimizer description: Audit and optimize Animate.css usage in web codebases — CSS weight (full min build vs CDN vs custom keyframe-only build), v3 vs v4 class problems (missing animate__ prefix, compat.css), JS-triggering bugs (animations that don't replay, missing animationend cleanup), infinite/hover animation repaint cost, delayed class lists, and the built-in prefers-reduced-motion support. Report with evidence first, then a fix plan the user approves before any code changes. Use whenever Animate.css comes up -- animate__ classes, animate.min.css, animate.compat.css, "CSS animation doesn't replay", "slim down animation CSS", or an Animate.css upgrade/migration from v3 to v4 -- even if the word "optimize" isn't used.

Animate.css Optimizer

Audit how a codebase uses Animate.css, report what is wasteful or broken, agree a plan, then fix it. The library is just CSS, so the wins are: not shipping 100+ animations you never use, getting the replay/animationend lifecycle right in JS-driven UIs, and not fighting the built-in prefers-reduced-motion support. Nothing gets edited before the plan is approved.

Workflow

1. Scope (quick)

• Find the project root (package.json with animate.css, or an HTML file with an animate.min.css / animate.compat.css link). Static sites count too; the script skips framework code the same way.
• Run python <skill-dir>/scripts/audit.py <project-root> [--json] — it detects how Animate.css is loaded (npm import / CDN / compat build), lists every animate__* or legacy animated * class actually used, flags unused-import waste, JS-triggering bugs, broken/renamed animation names, and reduced-motion handling. All stdlib, no app run.
• Note the framework: React/Vue/Svelte components re-render and for-animate classes differently from plain HTML; the v3→v4 migration matters most in older CMS/HTML templates.

2. Audit

The script finds the cheap stuff; you find the rest by reading. Load only the reference you need:

Sanity-check what the script can't see:

• Which animations actually run — grep the elements (not just the classes) and ask: is this above the fold or below it, one-shot or on a loop?
• CSS size ground truth — if you want numbers, find the served file (e.g. the CDN URL or node_modules/animate.css/animate.min.css) and note its raw/gzip size; don't invent numbers.

Mark findings Confirmed (seen in code/output) or Suspected (needs runtime checking, e.g. "the class isn't in the served CSS").

3. Report

Fill in assets/report-template.md, save as ANIMATE_CSS_REPORT.md in the project root (copy to the user too). Findings table sorted by impact/effort; each with evidence path:line, why it matters, fix, risk.

4. Plan — stop for approval

Turn the report into a short plan; present it and wait for an explicit "go" (use plan mode if available). Typical ordering:

1. Quick wins — dedupe CDN + npm imports, fix wrong animation names, self-host the CSS.
2. Structural — build or adopt a keyframe-only subset, replay/animationend cleanup in JS components, adding a reduced-motion override where the media query is known to be avoided.
3. Optional — migrating off animate.compat.css / v3 classes, replacing infinite animations with interaction-triggered ones. Each item lists files touched, expected effect, how to verify, rollback. Let the user drop or reorder items.

5. Fix

Only approved items. Work in small groups; after each, run whatever build/typecheck the project has (Mostly it's "open the page and watch", so also exercise the animations). Animate.css is CSS-only so its changes rarely break data, but class renames can break JS hooks on those classes — check both directions ([class*=animate__], getElementsByClassName("animate__...")).

6. Verify and wrap up

• DevTools: confirm the animation classes compute correctly, replays work (the JS-triggering checklist), prefers-reduced-motion emulation turns them off.
• CSS transfer before/after (raw and gzipped) if weight was a finding — report what shrank; state plainly any you couldn't measure.
• List deferred items and one suggested next step.

Principles

• Ship what you animate. The full build carries every animation; a custom build with only the used @imports is the intended, documented path when usage is small.
• CSS-first. Prefer the utility classes and --animate-duration/--animate-delay variables over JS timing; keep JS triggers minimal and cleaned up with animationend.
• Replay needs a class reset. Re-adding the same animation class without removing it first does nothing; the removal-then-rAF-then-add (or void offsetWidth) pattern is the fix.
• Never disable prefers-reduced-motion. Animate.css has honored the media query since 3.7 — flag any code that strips it; add interactions that don't depend on motion instead.
• Animate small, block-level elements. Not <html>/<body>, not inline elements, not huge areas; the docs' own gotchas list.
• Infinite animations are the exception, not the default — they repaint forever and motion-sensitive users suffer; justify each one.
• Measure rather than guess sizes. If you can't measure the stylesheet, say so; never present invented numbers.