sveltekit
Think in SvelteKit
SvelteKit is not just Svelte with folders. It is an application boundary system: route files define ownership of data, server code stays on the server, form submissions progressively enhance, and redirects/errors are part of control flow.
The core failure mode: writing SvelteKit like a client-side SPA with incidental server helpers. Fetching server-owned data from components. Hiding auth in hooks and assuming layouts protect endpoints. Returning class instances from load. Calling redirect() without throwing. Building JavaScript-only forms when native forms plus actions would work. These work until SSR, progressive enhancement, caching, or security boundaries matter.
Use this skill for app-level SvelteKit decisions. Use svelte5 for component internals: runes, snippets, component props, DOM events, accessibility, transitions, and component state.
How SvelteKit Thinks
Routes own application boundaries
1. File names are behavior. +page.svelte, +layout.server.ts, +page.server.ts, and +server.ts are not organization trivia; they decide where code runs and who can call it. See references/file-naming.md.
2. Route groups organize policy, not URLs. (app) and (auth) are for layout/auth/data boundaries without changing paths. Put protected routes under a protected layout; keep login/signup outside that group. See references/layout-patterns.md.
3. Layouts protect pages, not endpoints. A protected +layout.server.ts gates child pages. It does not protect sibling or child +server.ts endpoints; every endpoint must enforce auth itself. See references/auth.md.
Data flow should reveal ownership
More from joshuadavidthomas/agent-skills
frontend-design-principles
Create polished, intentional frontend interfaces. Use this skill when building any UI — dashboards, admin panels, landing pages, marketing sites, or web applications. Routes to specialized guidance based on context.
18writing-clearly-and-concisely
Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.
13crafting-effective-readmes
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
12reducing-entropy
Use when evaluating designs, reviewing code, or refactoring - measures success by total code in the final codebase, not effort to get there. Bias toward deletion.
10improving-prompts
Use when optimizing CLAUDE.md, AGENTS.md, custom commands, or skill files for Claude 4.5 models - applies documented Anthropic best practices systematically instead of inventing improvements
10diataxis
Structure, classify, and write documentation using the Diátaxis framework. Use when writing docs, README files, guides, tutorials, how-to guides, API references, or organizing documentation architecture. Also use when asked to improve documentation, restructure docs, decide what type of doc to write, or classify existing content. Covers tutorials, how-to guides, reference, and explanation.
8