agentleFS
MindrallyMindrally/skills/svelte/SKILL.md

svelte

Skill275 starsChanged 36 days agoApache-2.0View on GitHub

Modern Svelte 5 and SvelteKit development covering runes-based reactivity, snippets, SSR/SSG, and state management, including migration notes from legacy Svelte 4 syntax. Use when writing or reviewing Svelte components, deciding between runes and legacy reactive statements, building SvelteKit routes and load functions, or migrating a Svelte 4 codebase to Svelte 5.

9 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. 0 are common, 9 are distinctive, and 11 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write concise, technical components with accurate SvelteKit examples

    line 15
  2. Distinctive:

    Use TypeScript with proper naming conventions

    line 17
  3. Distinctive:

    Follow functional and declarative programming patterns

    line 19
  4. Very specific:

    Use $state for reactive state (replaces plain let bindings that needed reactivity)

    line 25
  5. Very specific:

    Use $derived for computed values (replaces $: computed = ...)

    line 26
  6. Very specific:

    Use $effect for side effects (replaces $: { ...

    line 27
  7. Very specific:

    Use $props for component properties (replaces export let prop)

    line 28
  8. Very specific:

    Use $bindable for two-way bindable props (replaces implicit bind: support on exported props)

    line 29
  9. Very specific:

    Use $inspect during development to log reactive value changes

    line 30
  10. Very specific:

    Component props: use let { propName } = $props() instead of multiple export let propName declarations.

    line 64
  11. Very specific:

    When maintaining an existing Svelte 4 codebase, keep using export let, on:event, and $: reactive statements consistently within that …

    line 67
  12. Very specific:

    Use scoped styling via Svelte's <style> tags

    line 71
  13. Distinctive:

    Keep styles co-located with components

    line 73
  14. Very specific:

    Use Svelte stores (or exported $state in .svelte.js/.svelte.ts modules under Svelte 5) for shared state

    line 77
  15. Distinctive:

    Use form actions for mutations

    line 86
  16. Distinctive:

    Use preloading for faster navigation

    line 93
  17. Very specific:

    Use Paraglide.js for i18n support

    line 98
  18. Distinctive:

    Use Vitest for unit testing

    line 103
  19. Distinctive:

    Use Lighthouse for performance auditing

    line 104
  20. Distinctive:

    Write comprehensive component tests

    line 105

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Svelte / SvelteKit

This skill covers Svelte and SvelteKit development with deep knowledge of SSR, SSG, and modern web patterns, including the Svelte 5 runes system and how it differs from legacy Svelte 4 reactivity.

Core Principles

  • Write concise, technical components with accurate SvelteKit examples
  • Emphasize SSR/SSG capabilities and performance optimization
  • Use TypeScript with proper naming conventions
  • Prioritize minimal client-side JavaScript through server-side rendering
  • Follow functional and declarative programming patterns

Svelte 5 Runes

Svelte 5 introduces runes — compiler-level primitives that make reactivity explicit, replacing Svelte 4's implicit let/$: reactivity.

  • Use $state for reactive state (replaces plain let bindings that needed reactivity)
  • Use $derived for computed values (replaces $: computed = ...)
  • Use $effect for side effects (replaces $: { ... } blocks)
  • Use $props for component properties (replaces export let prop)
  • Use $bindable for two-way bindable props (replaces implicit bind: support on exported props)
  • Use $inspect during development to log reactive value changes
  • Runes are compiler syntax, not imports — never import { $state } from 'svelte'. Only import genuine utilities that still require it, such as tick, untrack, mount, or unmount.

Svelte 4 vs. Svelte 5

Svelte 4 (legacy reactivity):

<script>
  let count = 0;
  $: double = count * 2;
  $: {
    if (count > 10) alert('Too high!');
  }
</script>
<button on:click={() => count++}>{count} / {double}</button>

Svelte 5 (runes):

<script>
  let count = $state(0);
  let double = $derived(count * 2);

  $effect(() => {
    if (count > 10) alert('Too high!');
  });
</script>
<button onclick={() => count++}>{count} / {double}</button>

Key differences to apply when writing or reviewing components:

  1. Reactivity is explicit — $state() marks reactive variables, $derived() replaces $: for computed values, $effect() replaces $: {} blocks for side effects.
  2. Event handling is standardized — Svelte 5 treats event handlers as ordinary HTML properties (onclick={handler}) instead of Svelte-specific directives (on:click={handler}). There are no more event modifiers like |preventDefault; call e.preventDefault() inline instead: onclick={e => { e.preventDefault(); handler(e); }}.
  3. Component props use let { propName } = $props() instead of multiple export let propName declarations. Mark a prop bindable from the parent with $bindable().
  4. Snippets replace slots for most reusable markup — {#snippet name(params)}...{/snippet} and {@render name(args)} reduce duplication and are more composable than named slots. Existing <slot> usage still works but prefer snippets in new Svelte 5 code.

When maintaining an existing Svelte 4 codebase, keep using export let, on:event, and $: reactive statements consistently within that codebase rather than mixing paradigms — full-file migrations to runes should be deliberate, not incidental.

Styling

  • Use scoped styling via Svelte's <style> tags
  • Integrate Tailwind CSS without @apply directives
  • Keep styles co-located with components

State Management

  • Use Svelte stores (or exported $state in .svelte.js/.svelte.ts modules under Svelte 5) for shared state
  • Implement state management via classes for complex scenarios, using $state fields for reactive class properties
  • Leverage Svelte's reactivity system effectively rather than reaching for external state libraries by default

SvelteKit Features

  • Use file-based routing
  • Implement proper load functions
  • Handle errors appropriately
  • Use form actions for mutations
  • Leverage server-side data loading

Performance

  • Focus on Web Vitals optimization
  • Minimize client-side JavaScript
  • Use preloading for faster navigation
  • Implement lazy loading where appropriate

Internationalization

  • Use Paraglide.js for i18n support
  • Implement proper locale handling

Testing

  • Use Vitest for unit testing
  • Use Lighthouse for performance auditing
  • Write comprehensive component tests

Accessibility

  • Ensure accessibility compliance
  • Use semantic HTML
  • Implement proper ARIA attributes

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.