NodeJSmith Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
MANDATORY PREPARATION
Read ${CLAUDE_CONFIG_DIR:-~/.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:
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
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:
- Assessment: What's wrong and why (your domain analysis above)
- Proposed changes: Specific changes ranked by impact, with rationale
- 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.
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:
- Changes made: List each file changed and what was done
- Verification: LLM self-check results (anti-pattern scan, consistency check). Note if Playwright was available for visual verification.
- Suggested next step: Any follow-up skills that would complement this work (e.g., after /i-typeset, suggest /i-polish for a final pass)