You can use 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 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:
# 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 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.