Svelte Architect
Use this skill when the task needs structure before code: greenfield Svelte
apps, SvelteKit feature design, migrations, routing decisions, state ownership,
server/client boundaries, adapter choices, or shared component systems.
Do not start by writing components. First determine which part of the Svelte
surface owns the behavior and which verification gate will prove it.
Operating contract
- Inspect the project before designing:
package.json, lockfile, Svelte and
SvelteKit versions, svelte.config.*, vite.config.*, route tree, tests,
and existing component conventions.
- Use the remote Svelte MCP for current documentation when the decision is
version-sensitive, migration-related, or touches Svelte 5 runes,
SvelteKit routing, load functions, actions, forms, adapters, or compiler
behavior.
- Write a concise architecture brief before implementation: goal,
constraints, selected Svelte surface, rejected alternatives, file plan,
verification plan, and residual risks.
- Prefer the existing project shape unless the request requires a structural
change. Local conventions beat generic framework preferences.
- Route follow-up work to the narrower skill:
svelte-component-engineer for component implementation,
sveltekit-engineer for route/server work, and svelte-verification
before completion.
MCP and CLI routing
- Use the Svelte MCP for docs lookup and source-aware checks when available.
- Use
sv for project creation, add-ons, official migrations, and installed
CLI behavior after checking the command help.
- Use package scripts for project-native gates; do not invent a new build or
test path when the repo already defines one.
- If MCP or CLI access is unavailable, state exactly what could not be verified
and continue with official docs or local evidence.
Read the relevant reference
| Reference |
Read when |
| architecture.md |
Choosing app structure, state boundaries, routing model, data flow, styling, or deployment shape. |
| source-verification.md |
Deciding which official or public source to trust, how to cite it, and how to avoid license-contaminated copying. |
Keep architecture decisions short enough to execute. A plan that does not name
files, owners, and verification gates is not ready.
1---2name: svelte-architect3description: Use when planning Svelte 5 or SvelteKit app architecture, major features, migrations, routing models, state ownership, adapter strategy, or shared component systems before implementation.4---56# Svelte Architect78Use this skill when the task needs structure before code: greenfield Svelte9apps, SvelteKit feature design, migrations, routing decisions, state ownership,10server/client boundaries, adapter choices, or shared component systems.1112Do not start by writing components. First determine which part of the Svelte13surface owns the behavior and which verification gate will prove it.1415## Operating contract16171. Inspect the project before designing: `package.json`, lockfile, Svelte and18 SvelteKit versions, `svelte.config.*`, `vite.config.*`, route tree, tests,19 and existing component conventions.202. Use the remote Svelte MCP for current documentation when the decision is21 version-sensitive, migration-related, or touches Svelte 5 runes,22 SvelteKit routing, load functions, actions, forms, adapters, or compiler23 behavior.243. Write a concise architecture brief before implementation: goal,25 constraints, selected Svelte surface, rejected alternatives, file plan,26 verification plan, and residual risks.274. Prefer the existing project shape unless the request requires a structural28 change. Local conventions beat generic framework preferences.295. Route follow-up work to the narrower skill:30 `svelte-component-engineer` for component implementation,31 `sveltekit-engineer` for route/server work, and `svelte-verification`32 before completion.3334## MCP and CLI routing3536- Use the Svelte MCP for docs lookup and source-aware checks when available.37- Use `sv` for project creation, add-ons, official migrations, and installed38 CLI behavior after checking the command help.39- Use package scripts for project-native gates; do not invent a new build or40 test path when the repo already defines one.41- If MCP or CLI access is unavailable, state exactly what could not be verified42 and continue with official docs or local evidence.4344## Read the relevant reference4546| Reference | Read when |47| ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |48| [architecture.md](references/architecture.md) | Choosing app structure, state boundaries, routing model, data flow, styling, or deployment shape. |49| [source-verification.md](references/source-verification.md) | Deciding which official or public source to trust, how to cite it, and how to avoid license-contaminated copying. |5051Keep architecture decisions short enough to execute. A plan that does not name52files, owners, and verification gates is not ready.