tomevault-io Creative Coder Skill
発火条件（リポジトリ判定）
- 依頼が「アニメーション」「インタラクション」「表現」「演出」「マイクロUX」「没入感」「スクロール/トランジション」なら適用する。
doc/input/rdd.mdにデザイン方針やトーンがあれば必ず参照する。
このSkillの基本方針（整理軸）
- 基本方針: 体験は「見た目」ではなく「状態遷移」と「時間」の設計。
- 制約優先: アクセシビリティとパフォーマンスを守る（prefers-reduced-motion、GPU負荷、INP/LCP）。
- 実装戦略: まず最小のプロトタイプで確認し、価値がある演出だけを残す。
思想（判断ルール）
- 動きは情報であり、ノイズにもなる。目的（視線誘導/状態変化の理解/気持ちよさ）を言語化する。
- すべてを動かさない。重要な瞬間だけ動かす（メリハリ）。
- a11yを壊さない（動きの抑制、コントラスト、フォーカス、操作可能性）。
- パフォーマンスは体験そのもの。レイアウトスラッシングを避け、軽い手段から選ぶ。
- 実装は「戻せる」ことが大事。切り替え可能な構成で入れる。
進め方（最初に確認する問い）
- この動きでユーザーに何を理解してほしい？（目的）
- どの環境が想定？（モバイル/低スペック/回線）
- どの操作に紐づく？（hover/click/scroll/route）
- reduced motion への対応は必要？（必要なら必須）
出力フォーマット（必ずこの順）
- 目的（体験として何を達成するか）
- 仕様（トリガー/状態/時間/イージング/停止条件）
- 実装方針（最小手段→必要なら段階的に強化）
- a11y配慮（reduced motion/フォーカス/操作）
- パフォーマンス配慮（計測ポイント）
- 次アクション（プロトタイプ→統合）
チェックリスト
- 動きの目的が説明できるか（見た目のためだけになっていないか）
-
prefers-reduced-motionに対応しているか - 重要操作（キーボード/フォーカス）が阻害されていないか
- レイアウト計算を増やしていないか（transform/opacity優先）
- 体感指標（INP/LCP）に悪影響がないか
よくある落とし穴
- 何でもアニメーションして情報密度が下がる
- reduced motion を無視して不快/危険な体験になる
- 重い実装（scrollハンドラ乱用等）でINPが悪化する
Converted and distributed by TomeVault — claim your Tome and manage your conversions.