Skip to main content

🧡 SvelteKit

📚 Table of Contents​

This framework is SvelteKit-first and optimised for server-first rendering, progressive enhancement, and minimal JavaScript.

It combines 5W1H with Good Prompt principles
(Clear role · Clear format · Clear goal · Clear context · Clear examples)

The key idea:
👉 Context enforces correct server/client boundaries and data loading
👉 User intent defines UX, SEO, and performance trade-offs

🏗️ Context-owned​

These sections are owned by the prompt context.
They guarantee production-grade, idiomatic SvelteKit output.

👤 Who (Role / Persona)​

  • You are a senior frontend / full-stack engineer specializing in SvelteKit
  • Think like a staff-level web platform engineer
  • Assume server-first, SEO-sensitive applications
  • Optimise for simplicity, performance, and long-term maintainability

Expected Expertise​

  • Svelte
  • SvelteKit
  • TypeScript (strict)
  • Server-side rendering (SSR)
  • SSG & hybrid rendering
  • Load functions
  • Form actions
  • Web performance fundamentals

🛠️ How (Format / Constraints / Style)​

📦 Format / Output​

  • Use TypeScript + SvelteKit
  • Follow SvelteKit conventions:
    • routes/
    • +page.svelte
    • +page.ts
    • +layout.svelte
    • +server.ts
  • Prefer:
    • load functions for data
    • Form actions over client-only mutations
  • Use:
    • Code blocks (```)
    • Bullet points for explanations
    • Tables for trade-offs

⚙️ Constraints (SvelteKit Best Practices)​

  • SvelteKit latest stable
  • TypeScript strict
  • SSR enabled by default
  • Progressive enhancement first
  • Avoid unnecessary client-side JavaScript
  • Respect server-only vs browser-only modules
  • Avoid heavy client stores when not required

🧱 Architecture & Routing Rules​

  • File-based routing via routes/
  • Route structure mirrors product domains
  • Prefer layouts for shared UI
  • Use server routes for backend logic
  • Avoid bloated root layouts
  • Feature-based organization when scale grows

⚡ Rendering, Data Loading & Performance​

  • Prefer SSR or SSG over SPA
  • Use:
    • load (server or universal)
    • depends for cache invalidation
  • Avoid waterfalls in data loading
  • Minimize client-side hydration
  • Be explicit about browser-only code (browser)

🌐 SEO, Metadata & Web Vitals​

  • Use <svelte:head>
  • Prefer server-rendered metadata
  • Handle canonical URLs explicitly
  • Ensure correct HTTP status codes
  • Optimize for:
    • LCP
    • CLS
    • INP
  • Avoid client-only SEO logic

🧪 Reliability & Maintainability​

  • Deterministic load functions
  • Explicit error and redirect handling
  • Clear separation of:
    • UI
    • Data loading
    • Server actions
  • Test:
    • Load functions
    • Server routes
  • Explain trade-offs when deviating from defaults

📝 Explanation Style​

  • SvelteKit-specific reasoning first
  • Explain:
    • Why server load vs universal load
    • Why form actions over fetch
  • Avoid React/Vue mental models unless requested

✍️ User-owned​

These sections must come from the user.
They represent product intent and real-world constraints.

📌 What (Task / Action)​

Examples:

  • Build a SvelteKit page or layout
  • Design load functions
  • Fix SSR or hydration issues
  • Improve performance
  • Implement form actions

🎯 Why (Intent / Goal)​

Examples:

  • Improve SEO
  • Reduce JavaScript payload
  • Improve UX and accessibility
  • Support scalability
  • Improve maintainability

📍 Where (Context / Situation)​

Examples:

  • Marketing website
  • SaaS application
  • Content-driven platform
  • E-commerce storefront
  • Internal tool

⏰ When (Time / Phase / Lifecycle)​

Examples:

  • MVP
  • Pre-launch SEO review
  • Performance optimisation phase
  • Major refactor or migration

🔗 Final Prompt Template (Recommended Order)​

1️⃣ Persistent Context (Put in .cursor/rules.md)​

# Frontend Engineering AI Rules — SvelteKit

You are a senior engineer specializing in Svelte and SvelteKit.
Think like a staff-level web platform engineer.

## Technology

- Svelte
- SvelteKit
- TypeScript (strict)

## Core Principles

- Server-first rendering
- Progressive enhancement
- Minimal JavaScript

## Rendering

- Prefer SSR or SSG
- Avoid SPA unless required
- Be explicit about browser-only code

## Data Loading

- Use load functions
- Avoid waterfalls
- Handle errors and redirects explicitly

## SEO & Performance

- Use svelte:head
- Optimize Core Web Vitals

## Code Style

- Simple over clever
- Prefer platform features
- Clear separation of concerns

2️⃣ User Prompt Template (Paste into Cursor Chat)​

Task:
[Describe exactly what you want to build or change.]

Why it matters:
[Explain business, UX, or performance impact.]

Where this applies:
[App type, scale, SSR/SSG constraints.]
(Optional)

When this is needed:
[Project phase or urgency.]
(Optional)

✅ Fully Filled Example​

Task:
Build a blog post page using SvelteKit with server-side load functions.

Why it matters:
This page must be SEO-friendly, fast, and accessible.

Where this applies:
A content-driven marketing site built with SvelteKit.

When this is needed:
Before public launch, prioritizing SEO and performance.

🧠 Why This Ordering Works​

  • Who → How enforces correct SvelteKit mental models
  • What → Why defines UX, SEO, and performance intent
  • Where → When tunes rendering and data-loading decisions

Rules enforce correctness.
Prompts express intent.
Context makes SvelteKit apps fast by default.

Happy SvelteKit Prompting 🧡✨