# GitHub Copilot CLI for SvelteKit: practical guide

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

Learn how to use GitHub Copilot CLI on SvelteKit projects: setup, instructions, prompts, testing, pitfalls, and running parallel agents with AgentVera.

**In short:**

- Put build, test, and lint commands plus SvelteKit file conventions in .github/copilot-instructions.md so the agent edits the right files.
- Use small, test-driven prompts for routes, load functions, and form actions, then run Vitest, Playwright, and svelte-check after each step.
- Watch for server/client boundary leaks, missing event.fetch, skipped invalidation, and stale UI after form actions.

[GitHub Copilot CLI](/en/agents/copilot-cli/) is a terminal coding agent you start by running `copilot` in a SvelteKit project. It reads project instructions from `.github/copilot-instructions.md` or `AGENTS.md`, edits files, and can run commands when you approve them. This guide shows a practical setup and working loop for SvelteKit, with attention to routes, load functions, form actions, and tests.

## Why SvelteKit’s file roles make Copilot CLI edits cleaner

SvelteKit’s file-based routing and explicit server/client boundaries give Copilot CLI enough structure to make precise edits without needing a large context window. The `+page.svelte`, `+page.server.ts`, and `+server.ts` conventions tell the agent exactly where presentation, data loading, and API logic belong. Because SvelteKit projects usually include `svelte-check`, Vitest, and Playwright scripts, you can ask the agent to run narrow verification commands after each change. Form actions, typed load functions, and `locals` objects are idiomatic enough that a small, focused prompt often produces code that fits the existing patterns; the agent just needs clear instructions about which file to touch and which command proves the change worked.

## Project instructions that keep the agent on the right side of the server/client line

Create a `.github/copilot-instructions.md` file at the repository root, or use `AGENTS.md` if you already keep agent instructions there. The file should list the exact commands you use to install, build, lint, check, and test the project, and it should state the folder conventions and SvelteKit-specific rules that prevent the two most common mistakes: server code leaking into client components and client-only logic being used during server-side rendering. A short, realistic example:

```markdown
# SvelteKit project instructions

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

## Conventions
- App source is in `src/`; routes are under `src/routes/`.
- Use `+page.svelte` for UI, `+page.server.ts` for load functions and form actions, and `+server.ts` for API endpoints.
- Keep server-only code out of `+page.svelte` and client-only code out of server modules.
- Use generated types from `./$types` when writing load functions and actions.
- Put shared utilities in `src/lib/` and import them as `$lib/...`.

## Rules
- Never import `$env/dynamic/private` into a client file.
- Run `npm run check` after any route or server change.
- Run the relevant unit test before asking for review.
- For mutations, prefer form actions over API routes unless an external client needs the endpoint.
```

If you are new to the agent itself, the [How to use GitHub Copilot CLI](/en/blog/how-to-use-copilot-cli/) guide covers the basics of starting a session and approving commands.

## A tight edit–test–diff loop with example prompts for routes and actions

Use a tight loop: state the goal, ask Copilot CLI to inspect the relevant SvelteKit files first, then make one small change, run the appropriate test or `npm run check`, review the diff, and only then move to the next step. Asking for a full feature in one prompt usually creates a large diff that hides SvelteKit boundary mistakes. Example prompts that work well on a SvelteKit project:

- `Inspect src/routes/dashboard/+page.server.ts and src/routes/dashboard/+page.svelte. Add a load function that returns the current user from locals.user, then update the page to show a sign-out button when a user exists. Run npm run check.`
- `Add a form action updateProfile in src/routes/profile/+page.server.ts that validates the name field with zod, updates the database, and returns { success: true } or { message }. Then add a Vitest test in src/routes/profile/+page.server.test.ts for the success and error paths.`
- `Write a Vitest test for src/lib/utils/formatDate.ts covering the long, short, and invalid date cases. Run npm run test:unit -- formatDate.`
- `Add a Playwright test that logs in with the existing test user, visits /projects, and asserts the heading Your projects is visible. Run it with npm run test:e2e -- projects.`
- `Refactor src/routes/api/projects/+server.ts to return error(404) when a project is not found, and make sure the existing unit tests pass.`

## What Copilot CLI does well in SvelteKit and where it needs a second look

SvelteKit’s explicit file roles make it easy to describe tasks, but they also create boundaries the agent can accidentally cross. This table helps you check the agent’s output:

| File | Purpose | What to verify in Copilot CLI edits |
|---|---|---|
| `+page.svelte` | Route UI, client-side interactivity | No server-only imports; no direct database calls. |
| `+page.server.ts` | Load functions and form actions | Uses `event.fetch` instead of global `fetch`; returns plain data. |
| `+server.ts` | Pure API endpoints | Returns `Response` or uses `json`/`error`; no UI markup. |
| `+page.ts` or `+layout.ts` | Universal load functions | Only isomorphic code; no `locals`, no browser-only APIs. |

Typical tasks the agent handles well include adding typed load functions, converting endpoints to form actions, generating Vitest tests, and fixing `svelte-check` errors. Watch closely for these SvelteKit-specific pitfalls:

- Importing `$env/dynamic/private` or database clients directly into `+page.svelte` or other client files.
- Forgetting to pass `event.fetch` to `fetch` calls in server load functions, which can break relative URLs and credentials.
- Skipping `invalidateAll()` or `invalidate()` after a form action, leaving stale UI data.
- Creating a `+server.ts` API endpoint for a form submission when a form action is simpler and handles progressive enhancement.
- Writing unit tests that import `$app/forms` or `$app/navigation` without mocks, causing confusing failures.
- Running Playwright against the wrong base URL or not waiting for SvelteKit hydration before asserting.

## Using svelte-check, Vitest, and Playwright as the agent’s verification layer

Make tests part of every prompt, not an afterthought. Tell Copilot CLI to run `npm run check` after route changes, `npm run test:unit` after logic changes, and `npm run test:e2e` after UI changes. For Playwright work, ask the agent to describe what it will assert before writing the test, then run the test and paste the failure output back into the conversation if it does not pass. This keeps the loop tight and avoids the agent compounding an incorrect assumption. For browser verification, the [AI agent browser testing](/en/blog/ai-agent-browser-testing/) guide shows how to let the agent inspect the running SvelteKit app and catch visual or hydration issues that unit tests miss.

## Parallel SvelteKit agents with AgentVera

AgentVera runs coding agents' real command line tools side by side in one window, each in its own terminal panel. For SvelteKit work, the most valuable pieces are parallel git worktrees so one agent can refactor `+server.ts` files while another works on Playwright tests without overwriting changes, automatic code review after an agent finishes a turn to catch boundary mistakes before merge, checkpoints that let you undo a bad form action refactor in one click, and a shared approval queue with desktop notifications so you only step in when an agent is blocked or needs review.

## Final workflow advice

The fastest way to get good results from GitHub Copilot CLI on SvelteKit is not a clever prompt; it is a short, honest instructions file and a loop of small changes, immediate verification, and diff review. Use the project’s own `svelte-check`, Vitest, and Playwright commands as the ground truth, keep server and client boundaries explicit, and treat every agent edit as a pull request you still need to approve.

## Frequently asked questions

**Can GitHub Copilot CLI scaffold a SvelteKit project?** Yes. Run copilot in an empty folder and ask it to create a new SvelteKit project with npm create svelte@latest, then install dependencies. It can also add example load functions or form actions if you ask for them.

**How do I point GitHub Copilot CLI to my SvelteKit instructions?** Create .github/copilot-instructions.md or AGENTS.md at the repository root. Include build, test, lint, and check commands, plus SvelteKit-specific rules like keeping server-only code out of +page.svelte.

**Does GitHub Copilot CLI run Playwright tests in SvelteKit?** It can run npm run test:e2e or the Playwright CLI when you ask. Tell it which test file or browser to use, and review generated test code for SvelteKit-specific selectors, login steps, and hydration waits.

**What are common SvelteKit mistakes GitHub Copilot CLI makes?** It may import server-only modules into client components, forget to pass event.fetch in load functions, or skip invalidate after form actions. Running npm run check and reviewing diffs catches most of these.

---

**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/