The published collection currently contains Svelte sections, with no SvelteKit recipes. This guide explains the recipe format for future entries.

Portable components are ordinary Svelte components that render the same way in any Svelte 5 project. Some website features, however, cannot be delivered as a component alone: they need routes, server code or form actions in your SvelteKit application. The catalogue models this with **integration levels** so you can tell the difference before you download anything.

## Integration levels

| Level               | What you get                                                                               | What you provide                                                                                                              |
| ------------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `presentational`    | Markup and styles driven by props.                                                         | Content.                                                                                                                      |
| `local-interaction` | Client-side behaviour that stays in the browser.                                           | Content. JavaScript must be enabled where the component says so.                                                              |
| `service-required`  | An interface for a service, such as a form.                                                | The service and every responsibility the component declares it does not implement.                                            |
| `kit-recipe`        | A SvelteKit integration pattern delivered as components, helper modules and snippet files. | A SvelteKit 2 project, the route files you create from the recipe, the declared configuration, and review of the server code. |

Recipes have the kind `integration-recipe` and the runtime `sveltekit`. When recipes are published, the kind and integration-level filters identify them.

## What to check in a recipe

- **Route files are yours to create.** Exported paths may not contain `+`, so a recipe never ships `+page.svelte`, `+page.server.ts`, `+server.ts` or similar files. Route code arrives as ordinary helper or snippet files, and the recipe's usage notes tell you which route file to create under `src/routes`, or which existing one to merge the code into.
- **Where files go.** Keep the recipe's other files at their relative paths, and keep server-only modules server-only (for example in `$lib/server`).
- **Server rendering.** The `ssr` field says whether it renders on the server. `client-only` parts must not run during server rendering.
- **Configuration.** Environment variables and service settings are listed under services and in the usage notes. Never commit secrets.
- **Limitations.** Read `usage.limitations` before adopting a recipe; it states what the recipe deliberately does not handle.

## Adapting recipes to your project

A recipe is a starting point written against a plain SvelteKit 2 application. Your project may already have hooks, layouts, authentication or its own form handling. Merge the recipe into those conventions instead of replacing them, and run your project's own checks afterwards.

Individual recipes are documented on their component pages as they are published. This page describes the model they follow, not a list of recipes.