mae616 Creative Coder Skill
発火条件（リポジトリ判定）
- 依頼が「アニメーション」「インタラクション」「表現」「演出」「マイクロUX」「没入感」「スクロール/トランジション」なら適用する。
doc/input/rdd.mdにデザイン方針やトーンがあれば必ず参照する。
このSkillの基本方針（整理軸）
- 基本方針: 体験は「見た目」ではなく「状態遷移」と「時間」の設計。
- 制約優先: アクセシビリティとパフォーマンスを守る（prefers-reduced-motion、GPU負荷、INP/LCP）。
- 実装戦略: まず最小のプロトタイプで確認し、価値がある演出だけを残す。
思想（判断ルール）
- 動きは情報であり、ノイズにもなる。目的（視線誘導/状態変化の理解/気持ちよさ）を言語化する。
- すべてを動かさない。重要な瞬間だけ動かす（メリハリ）。
- a11yを壊さない（動きの抑制、コントラスト、フォーカス、操作可能性）。
- パフォーマンスは体験そのもの。レイアウトスラッシングを避け、軽い手段から選ぶ。
- 実装は「戻せる」ことが大事。切り替え可能な構成で入れる。
進め方（最初に確認する問い）
- 設計の初手から動きを織り込めているか？（静的な見た目を固めてから足す、にしない＝motion-first。姿勢の詳細は
animation-principles） - この動きでユーザーに何を理解してほしい？（目的）
- どの環境が想定？（モバイル/低スペック/回線）
- どの操作に紐づく？（hover/click/scroll/route）
- reduced motion への対応は必要？（必要なら必須）
出力フォーマット（必ずこの順）
- 目的（体験として何を達成するか）
- 仕様（トリガー/状態/時間/イージング/停止条件）
- 実装方針（最小手段→必要なら段階的に強化）
- a11y配慮（reduced motion/フォーカス/操作）
- パフォーマンス配慮（計測ポイント）
- 次アクション（プロトタイプ→統合）
チェックリスト
- 動きの目的が説明できるか（見た目のためだけになっていないか）
-
prefers-reduced-motionに対応しているか - 重要操作（キーボード/フォーカス）が阻害されていないか
- レイアウト計算を増やしていないか（transform/opacity優先）
- 体感指標（INP/LCP）に悪影響がないか
表現を演繹する4つの問い（センスでなく手順で再現する）
表現の強さは美的センスではなく「文脈からの演繹」。まず project-design-language でメタファー（この世界の一言）を宣言し、以下を全要素（枠・背景・文言・数値表示まで）に問う:
- メタファーの物理: この世界が本物なら物理的に何が起きるはずか（発想でなく世界の辻褄から演出を導く）
- 3幕構成: この動きの始まり・山場・余韻はどこか
- 役割宣言: この要素は主役/脇役/背景のどれか（脇役は主役より暗く・小さく・遅く。数値上限トークンで規定する）
- 嘘探し: この画面のどこで世界の辻褄が破れているか（
deep-reviewの世界観整合チェックと対応）
描画技術の選定（Canvas 2D 手書きをデフォルトにしない）
毎フレーム再描画・描画量が多い実装（アニメーション/ゲーム/データビジュアライゼーション）では、まず確立した描画ライブラリを第一候補に置く。判断軸は「描画量 × 更新頻度」:
- 少 × 低頻度（静的/たまに再描画）→ Canvas 2D / SVG でも可（依存ゼロの利点を取る）
- 多 or 高頻度（毎フレーム・多数オブジェクト・エフェクト）→ WebGL系ライブラリに寄せる（2D中心: PixiJS / 表現・プロトタイプ: p5.js の WEBGL モード / 3D: three.js。採用条件は CLAUDE.md 準拠）
- 高頻度側は CPU 律速の Canvas 2D で頭打ちになりやすい。選定時点で GPU/WebGL に処理を逃がす前提にし、フレーム予算（例: 16.6ms/60fps）と FPS 計測を最初から組み込み、実測で律速要因を確認してから最適化する
- 描画方式に関わらず、ドメインロジックは純粋関数として描画から分離する（描画層だけ差し替えられる構造）
- ドグマ化しない: 「Canvas 2D 禁止」ではなく既定値の変更。軽量ケースの手書きは依然として妥当
演出実装のレシピ（進行率→パラメータの純粋関数）
時間演出は次の形で書くと、重なり・巻き戻しで破綻せずTDDできる:
- 進行率を正規化: 時間を 0..1 の進行率に変換する純粋関数群として書く（フェーズ境界は定数トークン化し、Vibe調整点にする）
- ランダム性は決定的に: 座標・インデックス由来の決定的擬似乱数（sinハッシュ等）でステートレスに生成する（
Math.randomは再現性を壊すため避ける） - 計算と描画を分離: 進行率→パラメータの計算関数と、描画関数を分ける。計算側だけ単体テストする
- 効果: 一時停止フックで任意の瞬間を検証できる、演出の重なりで状態が壊れない
よくある落とし穴
- 何でもアニメーションして情報密度が下がる
- reduced motion を無視して不快/危険な体験になる
- 重い実装（scrollハンドラ乱用等）でINPが悪化する