Sveltekit Structure
Lay out SvelteKit routes, nested layouts, error boundaries, and SSR/hydration patterns while scaffolding a solo SaaS or content site.
Overview
Sveltekit Structure is an agent skill for the Build phase that explains SvelteKit routing, layouts, error handling, SSR, and svelte:boundary conventions.
Install
npx skills add https://github.com/spences10/svelte-skills-kit --skill sveltekit-structureWhat is this skill?
- Maps `+page.svelte`, `+layout.svelte`, `+error.svelte`, and `+server.ts` roles in one quick-start table
- Documents nested dashboard-style layout trees with `{@render children()}` in root layouts
- Covers dynamic segments such as `posts/[id]` for parameterized routes
- Points to reference files: file-naming, layout-patterns, error-handling, svelte-boundary
- Explicit triggers: routing, layouts, error handling, SSR, and svelte:boundary
- 4 primary file types in quick-start: +page, +layout, +error, +server
Adoption & trust: 589 installs on skills.sh; 84 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps mis-naming SvelteKit files or breaking nested layouts when adding routes to a new app.
Who is it for?
Solo builders starting or extending a SvelteKit app who want file-based routing and layout rules in one skill.
Skip if: Non-Svelte frameworks, pure CSS-only tasks, or production deploy/CI where you need DevOps skills instead.
When should I use this skill?
Routing, layouts, error handling, SSR, or svelte:boundary work in a SvelteKit project.
What do I get? / Deliverables
You get a consistent `src/routes` tree with correct +page/+layout/+error/+server placement and pointers to boundary and hydration patterns.
- Route and layout folder plan
- Layout/error boundary placement decisions
Recommended Skills
Journey fit
Canonical shelf is Build because the skill documents file-based routing and UI structure—not distribution, validation, or ops. Frontend is the primary surface: +page, +layout, +error, +server, and svelte:boundary govern what users see and how pages compose.
How it compares
Use instead of generic React/Next routing advice when the repo is SvelteKit-specific.
Common Questions / FAQ
Who is sveltekit-structure for?
Indie developers and agents building SvelteKit web apps who need authoritative structure for routes, layouts, and error boundaries.
When should I use sveltekit-structure?
During Build frontend work when adding pages, dashboard sections, API +server routes, SSR boundaries, or fixing hydration-related layout issues.
Is sveltekit-structure safe to install?
It is documentation-only guidance with no built-in shell or network actions; still review the Security Audits panel on this page before trusting any skill package.
SKILL.md
READMESKILL.md - Sveltekit Structure
# SvelteKit Structure ## Quick Start **File types:** `+page.svelte` (page) | `+layout.svelte` (wrapper) | `+error.svelte` (error boundary) | `+server.ts` (API endpoint) **Routes:** `src/routes/about/+page.svelte` → `/about` | `src/routes/posts/[id]/+page.svelte` → `/posts/123` **Layouts:** Apply to all child routes. `+layout.svelte` at any level wraps descendants. ## Example ``` src/routes/ ├── +layout.svelte # Root layout (all pages) ├── +page.svelte # Homepage / ├── about/+page.svelte # /about └── dashboard/ ├── +layout.svelte # Dashboard layout (dashboard pages only) ├── +page.svelte # /dashboard └── settings/+page.svelte # /dashboard/settings ``` ```svelte <!-- +layout.svelte --> <script> let { children } = $props(); </script> <nav><!-- Navigation --></nav> <main>{@render children()}</main> <footer><!-- Footer --></footer> ``` ## Reference Files - [file-naming.md](references/file-naming.md) - File naming conventions - [layout-patterns.md](references/layout-patterns.md) - Nested layouts - [error-handling.md](references/error-handling.md) - +error.svelte placement - [svelte-boundary.md](references/svelte-boundary.md) - Component-level error/pending - [ssr-hydration.md](references/ssr-hydration.md) - SSR and browser-only code ## Notes - Layouts: `{@render children()}` | Errors: +error.svelte _above_ failing route - Groups: `(name)` folders don't affect URL | Client-only: check `browser` - **Last verified:** 2025-01-11 <!-- PROGRESSIVE DISCLOSURE GUIDELINES: - Keep this file ~50 lines total (max ~150 lines) - Use 1-2 code blocks only (recommend 1) - Keep description <200 chars for Level 1 efficiency - Move detailed docs to references/ for Level 3 loading - This is Level 2 - quick reference ONLY, not a manual LLM WORKFLOW (when editing this file): 1. Write/edit SKILL.md 2. Format (if formatter available) 3. Run: npx skills add . --list 4. If the skill is not discovered, check SKILL.md frontmatter formatting 5. Validate again to confirm --> # File Naming Conventions ## Core Files | File | Purpose | Runs | Example | | ------------------- | --------------------- | --------------------- | --------------------------------------------- | | `+page.svelte` | Page component | Client & Server (SSR) | `/routes/about/+page.svelte` → `/about` | | `+page.ts` | Universal load | Client & Server | Data for +page.svelte | | `+page.server.ts` | Server load & actions | Server only | DB queries, form actions | | `+layout.svelte` | Layout wrapper | Client & Server | Wraps child routes | | `+layout.ts` | Layout universal load | Client & Server | Data for +layout.svelte | | `+layout.server.ts` | Layout server load | Server only | Auth, user data | | `+error.svelte` | Error boundary | Client & Server | Shown when error thrown | | `+server.ts` | API endpoint | Server only | `/routes/api/users/+server.ts` → `/api/users` | ## Route Parameters | Pattern | Matches | Example | | -------------- | -------------- | ---------------------------------------------------------------- | | `[id]` | Single param | `/posts/[id]/+page.svelte` → `/posts/123` | | `[slug]` | Single param | `/blog