name: animejs-optimizer description: Audit and optimize anime.js usage (v3 API and the v4 rewrite) — v3 vs v4 API drift (targets/onComplete vs createTimeline/stagger/createScope), missing scope cleanup in React/Vue (useEffect-less anime() calls), per-frame callback weight (update/complete closures), timeline composition, SVG animation costs, stagger placements, and needless libraries for animations CSS could do. Report with evidence and a fix plan approved before edits. Use when the user mentions anime.js, anime(), stagger(), createTimeline, createScope, "anime.js doesn't replay/stop", or animations in a React/Vue app keeping running after unmount -- even if they don't say "optimize".

Anime.js Optimizer

Audit how a codebase uses anime.js, report what is wasted or broken, agree a plan, then fix. anime.js drives its own animation loop, so the classic failures are: imperative anime() calls in framework components that never stop on unmount, v3-style code pasted into a v4 install (or vice versa), heavy update handlers running per frame, and using the library for one-shots CSS could handle. Report first, plan approved, then edit.

Workflow

1. Scope (quick)

• Project root (package.json with animejs; record the major — v3 and v4 have completely different APIs).
• Run python <skill-dir>/scripts/audit.py <project-root> [--json] — detects v3 vs v4 usage style, anime( calls in framework components without cleanup, per-frame callback weights, timeline usage, distribution/stagger options, and mixed old/new API conflicts in one codebase.

2. Audit

Read the init/animation files the leads point to. Load references as fit:

Runtime checks the script can't do: does the animation continue after the component unmounts (dev: navigate away and listen), does the timeline replay correctly, is easing/duration hydrated from CSS or JS timers.

Mark findings Confirmed or Suspected.

3. Report

Fill in assets/report-template.md, save as ANIMEJS_REPORT.md in the project root. Group: version drift, lifecycle, per-frame cost, scope decisions.

4. Plan — stop for approval

1. Quick wins — remove/merge duplicate anime() calls, fix v3-on-v4 mismatches, kill update handlers that do nothing.
2. Structural — move into lifecycle-managed scopes (v4 createScope or useEffect + animation.control()/.remove()-style cleanup), extract timelines, hoist shared eased configs, replace one-shot animations with CSS where reasonable.
3. Optional — v3→v4 migration plan (its own item; behavior deltas exist), removing anime.js for static reveals. Per step: files, expected effect, verification, rollback. Let the user drop or reorder.

5. Fix

Approved items only. Anime edits change visible motion: verify each group by exercising the page (mount/unmount, replay, interruption mid-animation).

6. Verify and wrap up

• Unmount tests: navigate routes away and confirm no orphaned RAF.
• Reduced-motion emulation where applicable; on-replay check for JS-triggered animations.
• Report deltas honestly; deferred items + next step.

Principles

• One loop, one owner. Imperative animations belong to a component lifecycle; anything created outside one must be explicitly removed in cleanup.
• v3 and v4 are different libraries. The anime({targets,...}) object API does not run on v4; spot mixed codebases early (the script flags version drift).
• Per-frame handlers are the frame budget. Anything in update/per-frame callbacks runs 60/s; move work out of the loop.
• Don't animate what CSS animates. Static entrances with no interruption logic are often cheaper as CSS transitions; keep the library for timelines, orchestration and SVG work.
• Version decisions are plan items. Upgrading v3→v4 is a rewrite of call sites, never a bundled change.