creative-coder

Creative Coder Skill

Trigger conditions (repository determination)

• Apply if the request involves "animation," "interaction," "expression," "staging," "micro UX," "immersion," or "scroll/transition."
• doc/input/rdd.md If there is a design policy or tone in , always refer to it.

Basic policy of this Skill (organizing axes)

• Basic policy: Experience is not about "looks" but the design of "state transitions" and "time."
• Constraints first: Protect accessibility and performance (prefers-reduced-motion, GPU load, INP/LCP).
• Implementation strategy: First verify with a minimal prototype, and keep only the staging that has value.

Philosophy (decision rules)

1. Motion is information, and it can also be noise. Verbalize the purpose (gaze guidance/understanding of state changes/pleasantness).
2. Don't animate everything. Animate only at important moments (contrast).
3. Don't break a11y (motion reduction, contrast, focus, operability).
4. Performance is the experience itself. Avoid layout thrashing, and choose lightweight means first.
5. For implementation, being able to "revert" is important. Introduce it in a switchable configuration.

Approach (questions to confirm first)

• Are you incorporating motion from the very first step of design? (Don't fix the static appearance first and then add it = motion-first. For details on the stance, see animation-principles）
• What do you want users to understand through this motion? (Purpose)
• What environment is assumed? (Mobile/low-spec/network)
• What operation is it tied to? (hover/click/scroll/route)
• Is support for reduced motion necessary? (If necessary, it is mandatory)

Output format (always in this order)

1. Purpose (what to achieve as an experience)
2. Specification (trigger/state/time/easing/stop conditions)
3. Implementation policy (minimal means → strengthen step by step if necessary)
4. a11y considerations (reduced motion/focus/operation)
5. Performance considerations (measurement points)
6. Next actions (prototype → integration)

Checklist

• Can the purpose of the motion be explained? (Is it not just for appearance?)
• prefers-reduced-motion Is it compatible with ?
• Are important operations (keyboard/focus) not hindered?
• Is it not increasing layout calculations? (Prioritize transform/opacity)
• Does it not negatively affect perceived metrics (INP/LCP)?

Common pitfalls

• Animating everything reduces information density
• Ignoring reduced motion leads to an unpleasant/dangerous experience
• Heavy implementations (such as abusing scroll handlers) worsen INP