# Claude Code for SvelteKit: A Practical Engineering Guide

URL: https://agentvera.dev/en/blog/claude-code-for-sveltekit/ · Published: 2026-11-01

Use Claude Code in a SvelteKit project: set up CLAUDE.md, plan load functions, forms and tests, and run it alongside Vitest and Playwright.

**In short:**

- Write a CLAUDE.md with SvelteKit’s server/client rules, build, check and test commands before running claude.
- Work in small steps with plan-first prompts, then verify each change with pnpm check, Vitest and Playwright.
- Review every +page.server.ts, +page.ts and +server.ts change yourself; that is where the agent tends to slip.

You can use [Claude Code](/en/agents/claude-code/) in a SvelteKit project by running `claude` in the repository root, telling it your project conventions in CLAUDE.md, and treating it like a senior pairing engineer: plan first, make small changes, run the suite after each change. This guide covers the setup, working loop, SvelteKit-specific pitfalls, and verification flow that make the agent reliable instead of random.

## Claude Code as a SvelteKit pairing engineer

SvelteKit projects split cleanly into route modules, load functions, form actions, and endpoints. Claude Code can read the whole route tree and track the contract between `+page.svelte`, `+page.ts`, and `+page.server.ts`, so a change to a load function can include the corresponding prop type update in the page. It also handles Svelte component syntax well enough for small refactors, event handlers, and reactive state. The real value comes from giving it explicit instructions in CLAUDE.md and asking for one cohesive change at a time, rather than letting it free-run across many files. More on that workflow is in the [Claude Code best practices](/en/blog/claude-code-best-practices/) checklist.

## Give Claude Code a SvelteKit-native CLAUDE.md

The most important file is CLAUDE.md at the project root. Claude Code reads it at the start of a session. Keep it short enough that the agent actually follows it: commands, folder conventions, and SvelteKit-specific rules. Avoid repeating general advice like "write clean code"; those dilute the instructions that matter.

A realistic CLAUDE.md for a SvelteKit app using Vitest and Playwright looks like this:

```markdown
# CLAUDE.md

## Commands
- Install: pnpm install
- Dev: pnpm dev
- Build: pnpm build
- Check: pnpm check
- Lint: pnpm lint
- Unit tests: pnpm test:unit
- E2E tests: pnpm test:e2e

## Folder conventions
- Routes live in src/routes. Each route may have +page.svelte, +page.ts, +page.server.ts, and +server.ts.
- +page.server.ts contains server-only load functions and form actions.
- +page.ts contains shared load functions that also run on the client.
- Shared utilities go in src/lib, not next to route files.

## SvelteKit rules
- Do not import server-only modules, environment variables, or Node built-ins in +page.svelte, +page.ts, or client-side code.
- Keep load return types explicit, and do not pass sensitive data to the client unless it is safe to expose.
- Use named form actions in +page.server.ts; keep action names simple and exported.
- Run pnpm check and pnpm test:unit after any change to .ts, .svelte, or +server.ts files.
- Never edit .svelte-kit or build output.
```

This gives the agent the exact commands to verify its work and the two SvelteKit boundaries that cause most breakage. You can start the agent by running `claude` in the project folder; for more advanced plan-first sessions see the [Claude Code plan mode](/en/blog/claude-code-plan-mode/) guide.

## Plan, change, test, review

Use plan-first, small-step changes. Before asking for an implementation, ask for a short plan that names the files it will touch and which tests should change. Then let it implement one file or one behavior at a time, run `pnpm check`, `pnpm test:unit`, and the relevant Playwright spec, and review the diff before continuing.

Typical prompts for SvelteKit work:

- Add a load function to src/routes/dashboard/+page.server.ts that returns the current user from locals and a list of recent projects. Show the plan first.
- Convert the contact form to use a named form action in +page.server.ts, validate the email and message fields, and return errors with the previous form values.
- Move the user session lookup from +page.ts into +page.server.ts so it only runs on the server, then update the page props.
- Write a Vitest unit test for the form action validation in src/routes/checkout/+page.server.ts without hitting the network.
- Add a Playwright test for the login flow, including the form error state when the password is wrong.

Keep each prompt to one user-visible behavior or one boundary change. If the agent proposes touching more than two or three files, ask it to split the change into smaller commits.

## Reliable tasks and SvelteKit-boundary pitfalls

Claude Code is reliable for repetitive, well-scoped SvelteKit work: adding a new route with a load function, converting a page to form actions, adding server endpoints, writing Vitest cases for pure validation logic, and generating Playwright specs for a defined flow. It is also useful for stricter TypeScript fixes after `pnpm check`.

The places to watch closely are the SvelteKit-specific boundaries. The agent may import `$env/dynamic/private` or a database client into a `+page.ts` that runs in the browser; it may put server-only code in `+page.svelte` script blocks; it may return a full user object from a load function without stripping sensitive fields; or it may call a form action from the wrong side of a client/server split. Always review `+page.server.ts`, `+page.ts`, and `+server.ts` changes yourself, and look for `$lib/server` imports outside server modules.

| Task | Good prompt |
| --- | --- |
| Route with server data | Add /settings/+page.server.ts that loads profile data from the database and returns only the fields the page needs. |
| Form action | Add a named form action `updateProfile` to /settings/+page.server.ts, validate the display name, and return a field error object. |
| API endpoint | Create /api/health/+server.ts that returns JSON status ok and does not require auth. |
| Unit test | Write Vitest tests for the validateEmail helper in src/lib/validation.ts, including invalid cases. |
| E2E test | Add a Playwright test that submits the signup form with a taken email and expects the error message. |

## Verify with svelte-check, Vitest, and Playwright

The agent should treat `pnpm check`, `pnpm test:unit`, and `pnpm test:e2e` as non-negotiable after each meaningful change. For SvelteKit, add `svelte-check` if it is in your lint or check command; if not, keep the existing project commands. Ask the agent to run the specific Vitest file it touched first, then the full unit suite before moving on. For Playwright, run only the spec for the changed flow during the loop, and keep the full run for the end.

When the agent changes a load function, ask it to also update or add a Vitest test for the transformation logic rather than trying to test the server module directly through SvelteKit. For form actions, extract validation into a pure function in `src/lib` so it can be unit tested without SvelteKit internals. That keeps the agent’s changes verifiable and avoids brittle tests that depend on the dev server.

## Parallel agents on a SvelteKit repo with AgentVera

For larger SvelteKit work, running multiple agents side by side is practical when each works in its own git worktree, so a route refactor and an API endpoint change do not overwrite each other. AgentVera runs real command line agents such as Claude Code in separate terminal panels and can review each turn with a second model, linking findings to file:line. Checkpoints let you undo one turn and replay the session step by step, which is useful when an agent breaks a server/client boundary. Token budgets stop an agent at its cap without losing the conversation, so you can continue after inspecting the diff. That combination matters more for SvelteKit than running the same prompt twice in one workspace.

## Final notes

Claude Code becomes dependable in a SvelteKit project when you make the boundaries explicit in CLAUDE.md, keep requests small, and verify with the project’s own check and test commands. The agent can do a lot of route, load, action, and test work; the main job of the developer is to review the server/client seam and keep the working loop tight. With that discipline, it is closer to a reliable pair programmer than to a code generator.

## Frequently asked questions

**How do I set up Claude Code for a SvelteKit project?** Run claude in the project root and add a CLAUDE.md with the project’s package manager, build, check, lint and test commands. Include SvelteKit-specific rules such as never importing server-only code into +page.svelte or +page.ts, and keep load function props explicit.

**Can Claude Code write SvelteKit load functions and form actions correctly?** Yes, when the task is scoped and the conventions are in CLAUDE.md. Ask it to plan first, keep load functions server-side where possible, and return only the fields the page needs; review the generated +page.server.ts changes for sensitive data leaks.

**Does Claude Code work with Vitest and Playwright in SvelteKit?** It can write and run Vitest unit tests and Playwright specs if the test commands are in CLAUDE.md. Ask it to run the specific test file after a change, then the full suite before finishing.

**How do I stop Claude Code from breaking SvelteKit server/client boundaries?** Add explicit rules to CLAUDE.md about not importing $env/dynamic/private, $lib/server or Node built-ins in client code. After each change, run pnpm check and visually review every +page.ts, +page.server.ts and +server.ts diff before continuing.

---

**About AgentVera.** AgentVera is a desktop app for macOS, Windows and Linux, built by Solviera Teknoloji. It runs 18 AI coding agents (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) side by side, per project, in real terminals with the user's own CLI installs and logins. The free plan has unlimited agents. Download: https://agentvera.dev/en/download/ · Pricing: https://agentvera.dev/en/pricing/