svelte

name	svelte
user-invocable	false
description	Svelte/SvelteKitプロジェクトにおいて、UI=状態の直接的な反映という思想を軸に、コンパイル時最適化・状態管理・レンダリング・配信量の設計を整理する。Svelte、SvelteKit、.svelteファイル、リアクティビティ、$state/$derived、コンパイラ最適化、軽量UI、store設計、配信量削減に関する相談で必ず使うこと。ユーザーが「Svelteでアプリを作りたい」「ランタイムを減らしたい」「仮想DOMなしのフレームワーク」と言った場合にも適用する。

Svelte UI Compiler Skill

公式情報

• Svelte
• Svelte Docs
• SvelteKit
• SvelteKit Docs

このSkillの基本方針

• 基本方針: UIは state の直接的な反映。ランタイムではなくコンパイルで最適化する。
• 実行モデル: 仮想DOMではなく、DOM操作をコンパイル時に決定する。
• 状態管理: シンプルな state とリアクティビティを優先し、抽象を増やしすぎない。
• 配信量: ランタイムを極限まで薄くし、JS送信量を減らす。
• 参考: Svelte / SvelteKit

思想（判断ルール）

1. UIは state の結果であり、DOM更新は機械に任せる。
2. ランタイムで解決しない。可能な限りコンパイル時に決定する。
3. 抽象は必要最小限に留める（早すぎる共通化をしない）。
4. 書いたコードが、ほぼそのまま実行結果になることを重視する。
5. Webフレームワークの責務は「開発者の意図を最短経路でDOMに反映すること」。

進め方（最初に確認する問い）

• UIは「アプリ」寄り？「ドキュメント」寄り？
• 状態はローカル中心か、共有が多いか？
• 更新頻度は高いか？
• SSR/SSGは必要か？（SvelteKit前提）
• 配信量や初期表示は課題か？

出力フォーマット（必ずこの順）

1. 推奨方針（1〜3行）
2. 理由（コンパイルモデル / 配信量 / 保守性）
3. 設計案（状態配置 / コンポーネント構造 / レンダリング戦略 / 配信）
4. チェックリスト
5. 落とし穴
6. 次アクション

チェックリスト

• stateが単純に保たれているか
• 書いたコードと挙動の距離が遠くなっていないか
• 抽象化が「気持ちよさ」を損なっていないか
• ランタイム依存が増えていないか
• SSR/SSGの選択理由が説明できるか

よくある落とし穴

• React的な設計（過剰な状態持ち上げ）をそのまま持ち込む
• store を乱用して、かえって依存関係が見えなくなる
• 「魔法」に見えて理解を止めてしまう
• SvelteKit の規約を無視して自前ルーティングを始める