Svelte UI Compiler Skill

公式情報

• Svelte
• Svelte Docs
• SvelteKit
• SvelteKit Docs

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

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

この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 の規約を無視して自前ルーティングを始める