# Creative Coder

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

- Skill: `mae616/creative-coder` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mae616/creative-coder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mae616/creative-coder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools, Web & Frontend
- Author: mae616 (https://skillmd.com/u/mae616)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/mae616/creative-coder

---


# 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）に悪影響がないか

## 表現を演繹する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が悪化する