Creative Coder

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

• 依頼が「アニメーション」「インタラクション」「表現」「演出」「マイクロ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）に悪影響がないか

表現を演繹する4つの問い（センスでなく手順で再現する）

表現の強さは美的センスではなく「文脈からの演繹」。まず project-design-language でメタファー（この世界の一言）を宣言し、以下を全要素（枠・背景・文言・数値表示まで）に問う:

1. メタファーの物理: この世界が本物なら物理的に何が起きるはずか（発想でなく世界の辻褄から演出を導く）
2. 3幕構成: この動きの始まり・山場・余韻はどこか
3. 役割宣言: この要素は主役/脇役/背景のどれか（脇役は主役より暗く・小さく・遅く。数値上限トークンで規定する）
4. 嘘探し: この画面のどこで世界の辻褄が破れているか（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が悪化する