NodeJSmith/i-animate

Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.

MANDATORY PREPARATION

Read ${CLAUDE_HOME:-~/.claude}/skills/i-frontend-design/SKILL.md for design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding — if no design context exists yet, you MUST run /i-teach-impeccable first. Additionally gather: performance constraints.

---

Assess Animation Opportunities

Analyze where motion would improve the experience:

1. Identify static areas:

   • Missing feedback: Actions without visual acknowledgment (button clicks, form submission, etc.)
   • Jarring transitions: Instant state changes that feel abrupt (show/hide, page loads, route changes)
   • Unclear relationships: Spatial or hierarchical relationships that aren't obvious
   • Lack of delight: Functional but joyless interactions
   • Missed guidance: Opportunities to direct attention or explain behavior

2. Understand the context:

   • What's the personality? (Playful vs serious, energetic vs calm)
   • What's the performance budget? (Mobile-first? Complex page?)
   • Who's the audience? (Motion-sensitive users? Power users who want speed?)
   • What matters most? (One hero animation vs many micro-interactions?)

If any of these are not answered by design context (design/context.md, .impeccable.md, or design/direction.md), STOP and call the AskUserQuestion tool to clarify. Use the answer to inform your animation strategy. If the answer is unclear or deferred, proceed with subtle, opacity-only transitions as the safe default.

CRITICAL: Respect prefers-reduced-motion. Always provide non-animated alternatives for users who need them.

Plan Animation Strategy

Create a purposeful animation plan:

• Hero moment: What's the ONE signature animation? (Page load? Hero section? Key interaction?)
• Feedback layer: Which interactions need acknowledgment?
• Transition layer: Which state changes need smoothing?
• Delight layer: Where can we surprise and delight?

IMPORTANT: One well-orchestrated experience beats scattered animations everywhere. Focus on high-impact moments.

---

Propose Changes

After analyzing the current state, present your proposed changes to the user:

1. Assessment: What's wrong and why (your domain analysis above)
2. Proposed changes: Specific changes ranked by impact, with rationale
3. Verification plan: What to check after implementation (LLM self-check items + Playwright verification if available)

Then STOP and confirm before implementing:

AskUserQuestion:
  question: "Here's what I propose. How would you like to proceed?"
  header: "Confirm"
  options:
    - label: "Implement"
      description: "Looks good — go ahead and make these changes."
    - label: "Refine scope"
      description: "I want to adjust what's included before you start."
    - label: "Challenge this first"
      description: "I'll run /mine.challenge against your proposal before we proceed."
    - label: "Stop here"
      description: "Don't implement anything. The proposal is in this conversation only."

If "Implement" → proceed to implementation below. If "Refine scope" → ask what to change, update proposal, re-confirm.

<!-- CHALLENGE-CALLER -->

If "Challenge this first" → invoke /mine.challenge inline against the proposal, read findings, revise proposal, re-present this gate. If "Stop here" → end the skill.

---

Implement Animations

Work across these categories, weighted toward the hero moment and feedback layer from your plan: entrance (staggered page-load reveals, hero, scroll-triggered, modal entry), micro-interactions (button hover/click, input focus, validation, toggles), state transitions (show/hide, expand/collapse, loading, success/error), navigation (page/tab transitions, carousels, scroll effects), and delight (empty-state float, completion flourishes, easter eggs). You know how each is built — the load-bearing details are the timing and easing below.

Technical Implementation

Timing & Easing

Durations by purpose:

• 100-150ms: Instant feedback (button press, toggle)
• 200-300ms: State changes (hover, menu open)
• 300-500ms: Layout changes (accordion, modal)
• 500-800ms: Entrance animations (page load)

Easing curves (use these, not CSS defaults):

/* Recommended - natural deceleration */
--ease-out-quart: cubic-bezier(0.25, 1, 0.5, 1);    /* Smooth, refined */
--ease-out-quint: cubic-bezier(0.22, 1, 0.36, 1);   /* Slightly snappier */
--ease-out-expo: cubic-bezier(0.16, 1, 0.3, 1);     /* Confident, decisive */

/* AVOID - feel dated and tacky */
/* bounce: cubic-bezier(0.34, 1.56, 0.64, 1); */
/* elastic: cubic-bezier(0.68, -0.6, 0.32, 1.6); */

Exit animations are faster than entrances. Use ~75% of enter duration.

Performance & Accessibility

Animate transform and opacity only (GPU-composited); will-change sparingly. Always honor reduced motion:

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

NEVER:

• Use bounce or elastic easing — they feel dated and draw attention to the animation itself. Spring physics with zero visible overshoot is permitted (e.g., React Spring with high tension/friction).
• Animate layout properties (width, height, top, left) — use transform instead
• Use durations over 500ms for feedback — it feels laggy
• Animate without purpose, or animate everything — animation fatigue is real
• Block interaction during animations unless intentional

Also review the anti-patterns reference for general visual anti-patterns to avoid when styling animated elements.

Verify Quality

Test animations thoroughly:

• Smooth at 60fps: No jank on target devices
• Feels natural: Easing curves feel organic, not robotic
• Appropriate timing: Not too fast (jarring) or too slow (laggy)
• Reduced motion works: Animations disabled or simplified appropriately
• Doesn't block: Users can interact during/after animations
• Adds value: Makes interface clearer or more delightful

Remember: Motion should enhance understanding and provide feedback, not just add decoration. Animate with purpose, respect performance constraints, and always consider accessibility.

Completion

After implementation, summarize in conversation:

1. Changes made: List each file changed and what was done
2. Verification: LLM self-check results (anti-pattern scan, consistency check). Note if Playwright was available for visual verification.
3. Suggested next step: Any follow-up skills that would complement this work (e.g., after /i-typeset, suggest /i-polish for a final pass)