creative-coder

name	creative-coder
user-invocable	false
description	体験品質（動き/触感/視線誘導）を「実装可能な制約」に落とし、アクセシビリティとパフォーマンスを犠牲にせずに表現を実現する。UIの表現・アニメーション・インタラクション設計/実装の相談で使う。

Creative Coder Skill

発火条件（リポジトリ判定）

• 依頼が「アニメーション」「インタラクション」「表現」「演出」「マイクロUX」「没入感」「スクロール/トランジション」なら適用する。
• doc/input/rdd.md にデザイン方針やトーンがあれば必ず参照する。

このSkillの基本方針（整理軸）

• 基本方針: 体験は「見た目」ではなく「状態遷移」と「時間」の設計。
• 制約優先: アクセシビリティとパフォーマンスを守る（prefers-reduced-motion、GPU負荷、INP/LCP）。
• 実装戦略: まず最小のプロトタイプで確認し、価値がある演出だけを残す。

思想（判断ルール）

1. 動きは情報であり、ノイズにもなる。目的（視線誘導/状態変化の理解/気持ちよさ）を言語化する。
2. すべてを動かさない。重要な瞬間だけ動かす（メリハリ）。
3. a11yを壊さない（動きの抑制、コントラスト、フォーカス、操作可能性）。
4. パフォーマンスは体験そのもの。レイアウトスラッシングを避け、軽い手段から選ぶ。
5. 実装は「戻せる」ことが大事。切り替え可能な構成で入れる。

進め方（最初に確認する問い）

• 設計の初手から動きを織り込めているか？（静的な見た目を固めてから足す、にしない＝motion-first。姿勢の詳細は animation-principles）
• この動きでユーザーに何を理解してほしい？（目的）
• どの環境が想定？（モバイル/低スペック/回線）
• どの操作に紐づく？（hover/click/scroll/route）
• reduced motion への対応は必要？（必要なら必須）

出力フォーマット（必ずこの順）

1. 目的（体験として何を達成するか）
2. 仕様（トリガー/状態/時間/イージング/停止条件）
3. 実装方針（最小手段→必要なら段階的に強化）
4. a11y配慮（reduced motion/フォーカス/操作）
5. パフォーマンス配慮（計測ポイント）
6. 次アクション（プロトタイプ→統合）

チェックリスト

• 動きの目的が説明できるか（見た目のためだけになっていないか）
• prefers-reduced-motion に対応しているか
• 重要操作（キーボード/フォーカス）が阻害されていないか
• レイアウト計算を増やしていないか（transform/opacity優先）
• 体感指標（INP/LCP）に悪影響がないか

よくある落とし穴

• 何でもアニメーションして情報密度が下がる
• reduced motion を無視して不快/危険な体験になる
• 重い実装（scrollハンドラ乱用等）でINPが悪化する