svelte5
Think in Svelte 5
You already know Svelte syntax. This skill changes your defaults — what you reach for first when designing a component, placing state, modeling reactivity, and reviewing UI code.
The core failure mode: writing Svelte that compiles but thinks like React, Vue, or Svelte 4. Effects that synchronize derived state. Props copied into local state. Global stores for everything. Two-way binding as the default API. Clickable divs. on:click, export let, <slot>, and createEventDispatcher in new Svelte 5 code. Components that are really DOM actions. Actions that are really components. These work until they don't.
Svelte's strength is that the component is a small reactive program whose dependencies are visible. Write code that lets the compiler and the DOM do the work. Keep dataflow direct, state ownership obvious, and markup semantic.
This skill is the general-purpose entry point for Svelte component review. For SvelteKit routes, load, form actions, remote functions, cookies, auth, endpoints, redirects, server errors, deployment, or app-level SSR data flow, also use sveltekit.
Treat these as strong defaults, not rigid laws: when unsure, choose the approach that makes ownership, dependencies, and user semantics more explicit.
How Svelte Thinks
Make reactivity visible
1. Reactivity is read-tracked. A $derived or $effect depends on the reactive values it reads while running. If an effect reruns unexpectedly, inspect what it reads — don't hunt for a dependency array. See references/read-tracked-reactivity.md.
2. Derived state is $derived, not $effect. If a value is a pure function of other state, derive it. Effects are for side effects, not keeping variables in sync. See references/effect-driven-state.md.
More from joshuadavidthomas/agent-skills
frontend-design-principles
Create polished, intentional frontend interfaces. Use this skill when building any UI — dashboards, admin panels, landing pages, marketing sites, or web applications. Routes to specialized guidance based on context.
17writing-clearly-and-concisely
Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.
13crafting-effective-readmes
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
12reducing-entropy
Use when evaluating designs, reviewing code, or refactoring - measures success by total code in the final codebase, not effort to get there. Bias toward deletion.
10improving-prompts
Use when optimizing CLAUDE.md, AGENTS.md, custom commands, or skill files for Claude 4.5 models - applies documented Anthropic best practices systematically instead of inventing improvements
10diataxis
Structure, classify, and write documentation using the Diátaxis framework. Use when writing docs, README files, guides, tutorials, how-to guides, API references, or organizing documentation architecture. Also use when asked to improve documentation, restructure docs, decide what type of doc to write, or classify existing content. Covers tutorials, how-to guides, reference, and explanation.
8