mcpField
S
sveltekit

sveltekit

github.com/sjuneparkDevelopment141 installsUpdated 3w ago
Repository

About sveltekit

A skill for SvelteKit developers handling app- and route-level behavior. It focuses on correct data flow and boundaries across SSR, hydration, navigation, and progressive enhancement.

Key features

  1. 01Inspect project conventions before changes
  2. 02Choose server and client boundaries
  3. 03Plan data flow before UI details
  4. 04Account for navigation and SSR behavior
  5. 05Validate server, browser, and enhanced paths

Use cases

  1. 01Implementing or changing SvelteKit routes
  2. 02Building forms, mutations, or API endpoints
  3. 03Handling authentication, cookies, or request-local state
  4. 04Debugging SSR, hydration, or navigation behavior

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sjunepark/agent-scripts --skill sveltekit

After installing, type/sveltekitin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

agents/
openai.yaml
guides/
auth-cookies.md
forms-endpoints.md
load-routing.md
migration.md
ssr-hydration.md
state-navigation.md

Details

From the project README

SvelteKit

Optimize for route and data flows that stay correct under SSR, hydration, navigation, and progressive enhancement. Focus on boundaries and the shortest correct implementation.

Scope

Use this skill when the hard part is app-level or route-level behavior. If the task is mostly about component internals, runes, snippets, local state, or styling, use the svelte skill.

Workflow

  1. Establish the local style before changing code.

    • Inspect package.json, svelte.config.*, the route tree, hooks, and nearby route files.
    • Prefer existing conventions in touched files unless the task is an explicit migration.
    • For new code, default to current SvelteKit APIs and typed route files.
  2. Choose the server/client boundary before writing code.

    • Put server-only work in +page.server.*, +layout.server.*, +server.*, hooks, or $lib/server/*.
    • Put reusable view logic in components or $lib, not route files.
    • Keep request-specific mutable state out of shared modules so server state cannot leak across users.
    • Keep route flow obvious: params, URL, cookies, and locals -> load or action -> typed props -> component.
  3. Solve data flow before UI details.

    • Decide whether truth belongs in the URL, server data, component state, snapshots, context, or a shared reactive object.
    • Derive state instead of synchronizing copies.
    • Decide whether data reruns automatically or only after targeted invalidation.
  4. Make navigation and SSR behavior explicit.

    • Check whether code runs on the server, in the browser, or both.
    • Decide whether state survives reloads, deep links, history navigation, or only the current render.
    • Check whether route components are reused across navigation and whether anything must reset explicitly.
  5. Validate the relevant server, browser, and progressively enhanced paths with the repository's existing checks.

    • When behavior is version-sensitive, verify it against the installed Svelte and SvelteKit versions and current official documentation.

Topic guides

Comments

Markdown supported