oimiragieo Svelte Expert
svelte 5 component structure snippets
When reviewing or writing code, apply these guidelines:
- Use snippets and render tags to create reusable chunks of markup inside components.
- Snippets help reduce duplication and enhance maintainability.
svelte 5 general rules
When reviewing or writing code, apply these guidelines:
- Always use Svelte 5 instead of Svelte 4.
- Use runes for controlling reactivity; runes replace certain non-runes features and provide more explicit control over state and effects.
- Treat event handlers as properties for simpler use and integration.
svelte 5 reactivity handling
When reviewing or writing code, apply these guidelines:
- Prefer runes over reactive declarations (
$:) for reactivity, e.g.bind:value - Treat event handlers as properties, simplifying their use.
svelte and sveltekit general rules
When reviewing or writing code, apply these guidelines:
- Write concise, technical TypeScript or JavaScript code with accurate examples.
- Use functional and declarative programming patterns; avoid unnecessary classes except for state machines.
- Prefer iteration and modularization over code duplication.
- Structure files: component logic, markup, styles, helpers, types.
- Follow Svelte's official documentation for setup and configuration: https://svelte.dev/docs
- Use lowercase with hyphens for component files (e.g.,
components/auth-form.svelte). - Use PascalCase for component names in imports and usage.
- Use camelCase for variables, functions, and props.
- Implement proper component composition and reusability.
- Use Svelte's props for data passing.
- Leverage Svelte's reactive declarations for local state management.
- Ensure proper semantic HTML structure in Svelte components.
- Implement ARIA attributes where necessary.
- Ensure keyboard navigation support for interactive elements.
- Use Svelte's bind:this for managing focus programmatically.
- Embrace Svelte's simplicity and avoid over-engineering solutions
Consolidated Skills
This expert skill consolidates 1 individual skills:
- svelte-expert
Iron Laws
- NEVER use Svelte 4 reactive declarations (
$:) in new code — use Svelte 5 runes - ALWAYS use file-based routing and
loadfunctions for data fetching in SvelteKit - NEVER use stores for local component state — use
$stateand$derivedrunes - ALWAYS implement
+error.svelteerror boundaries for every route group that can fail - NEVER skip accessibility semantics — ensure ARIA attributes and keyboard navigation
Anti-Patterns
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| Using Svelte 4 reactive syntax | Legacy patterns conflict with rune-based reactivity | Use $state(), $derived(), and $effect() runes in all new code |
| Global stores for local state | Unnecessary coupling; component state leaks | Use $state rune for component-local reactive state |
| Ignoring SvelteKit routing conventions | Manual routing breaks framework integration | Follow file-based routing; use +page.svelte and +layout.svelte |
Missing +error.svelte handlers |
Unhandled route errors produce blank pages | Add +error.svelte to every route group that can fail |
| Skipping accessibility attributes | Screen readers and keyboard users cannot use the UI | Always add ARIA labels and test keyboard navigation |
Memory Protocol (MANDATORY)
Before starting:
cat .claude/context/memory/learnings.md
After completing: Record any new patterns or exceptions discovered.
ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.