Svelte

---
name: svelte
category: tech
user-invocable: false
description: Svelte/SvelteKitプロジェクトにおいて、UI=状態の直接的な反映という思想を軸に、コンパイル時最適化・状態管理・レンダリング・配信量の設計を整理する。doc/input/rdd.md に「技術スタック Svelte」または「技術スタック SvelteKit」がある場合や、Svelteの設計・パフォーマンス・構造理解の相談で使う。
---

# Svelte UI Compiler Skill

## 公式情報
- [Svelte](https://svelte.dev)
- [Svelte Docs](https://svelte.dev/docs)
- [SvelteKit](https://kit.svelte.dev)
- [SvelteKit Docs](https://kit.svelte.dev/docs)

## 発火条件（リポジトリ判定）
- `doc/input/rdd.md` に `技術スタック Svelte` または `技術スタック SvelteKit` が記載されている場合、このSkillを優先適用する。
- 記載がなくても、依頼内容が Svelte / SvelteKit / コンパイラ最適化 / 軽量UI / 状態管理 / 配信量削減 に関係する場合は適用する。

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

## 思想（判断ルール）
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 の規約を無視して自前ルーティングを始める