| name | svelte |
| category | tech |
| description | Svelte/SvelteKitプロジェクトにおいて、UI=状態の直接的な反映という思想を軸に、コンパイル時最適化・状態管理・レンダリング・配信量の設計を整理する。doc/rdd.md に「技術スタック Svelte」または「技術スタック SvelteKit」がある場合や、Svelteの設計・パフォーマンス・構造理解の相談で使う。 |
Svelte UI Compiler Skill
公式情報
発火条件（リポジトリ判定）
doc/rdd.mdに技術スタック Svelteまたは技術スタック SvelteKitが記載されている場合、このSkillを優先適用する。- 記載がなくても、依頼内容が Svelte / SvelteKit / コンパイラ最適化 / 軽量UI / 状態管理 / 配信量削減 に関係する場合は適用する。
このSkillの基本方針（整理軸）
- 基本方針: UIは state の直接的な反映。ランタイムではなくコンパイルで最適化する。
- 実行モデル: 仮想DOMではなく、DOM操作をコンパイル時に決定する。
- 状態管理: シンプルな state とリアクティビティを優先し、抽象を増やしすぎない。
- 配信量: ランタイムを極限まで薄くし、JS送信量を減らす。
- 参考: Svelte / SvelteKit
思想（判断ルール）
- UIは state の結果であり、DOM更新は機械に任せる。
- ランタイムで解決しない。可能な限りコンパイル時に決定する。
- 抽象は必要最小限に留める（早すぎる共通化をしない）。
- 書いたコードが、ほぼそのまま実行結果になることを重視する。
- Webフレームワークの責務は「開発者の意図を最短経路でDOMに反映すること」。
進め方（最初に確認する問い）
- UIは「アプリ」寄り？「ドキュメント」寄り？
- 状態はローカル中心か、共有が多いか？
- 更新頻度は高いか？
- SSR/SSGは必要か？（SvelteKit前提）
- 配信量や初期表示は課題か？
出力フォーマット（必ずこの順）
- 推奨方針（1〜3行）
- 理由（コンパイルモデル / 配信量 / 保守性）
- 設計案（状態配置 / コンポーネント構造 / レンダリング戦略 / 配信）
- チェックリスト
- 落とし穴
- 次アクション
チェックリスト
- stateが単純に保たれているか
- 書いたコードと挙動の距離が遠くなっていないか
- 抽象化が「気持ちよさ」を損なっていないか
- ランタイム依存が増えていないか
- SSR/SSGの選択理由が説明できるか
よくある落とし穴
- React的な設計（過剰な状態持ち上げ）をそのまま持ち込む
- store を乱用して、かえって依存関係が見えなくなる
- 「魔法」に見えて理解を止めてしまう
- SvelteKit の規約を無視して自前ルーティングを始める