Svelte Component Engineer
Use this skill for component-level implementation in Svelte 5 projects. It
covers .svelte, .svelte.ts, and .svelte.js work, including props, runes,
snippets, event callbacks, bindings, accessibility, styles, and tests.
Operating contract
- Inspect adjacent components and project conventions before editing.
- Use Svelte MCP documentation for current syntax, warnings, and compiler
behavior when touching runes, snippets, actions, transitions, bindings, or
migration-sensitive code.
- Keep state minimal: source state, derived state, and effects must each have a
distinct reason to exist.
- Keep components readable at the call site. Prefer explicit props and event
contracts over hidden module state.
- Preserve accessibility and keyboard behavior while changing markup.
- After edits, route to
svelte-verification for autofix, checks, tests, and
browser validation when applicable.
Implementation defaults
- Match the project's TypeScript and formatting conventions.
- Keep SSR compatibility unless the component is intentionally browser-only.
- Use keyed lists when identity matters.
- Avoid broad reactive effects for simple derivations.
- Keep DOM reads, browser APIs, timers, and subscriptions contained and cleaned
up.
- Use CSS custom properties or component-scoped styles for local theming; do not
introduce a design system unless the task requires it.
- Keep errors, loading, empty, and disabled states visible in the implementation
when the user flow needs them.
Read the relevant reference
| Reference |
Read when |
| svelte-5-components.md |
Writing or reviewing runes, props, derived values, snippets, events, bindings, or component modules. |
| component-review.md |
Checking accessibility, SSR behavior, performance, and maintainability before finalizing component code. |
If the code depends on behavior that the local project or MCP docs do not prove,
state the uncertainty and verify before broadening the change.
1---2name: svelte-component-engineer3description: Use when writing, editing, reviewing, or debugging Svelte 5 components, .svelte.ts modules, props, runes, snippets, bindings, events, accessibility, styles, or component tests. Do not use for route/server-only SvelteKit work.4---56# Svelte Component Engineer78Use this skill for component-level implementation in Svelte 5 projects. It9covers `.svelte`, `.svelte.ts`, and `.svelte.js` work, including props, runes,10snippets, event callbacks, bindings, accessibility, styles, and tests.1112## Operating contract13141. Inspect adjacent components and project conventions before editing.152. Use Svelte MCP documentation for current syntax, warnings, and compiler16 behavior when touching runes, snippets, actions, transitions, bindings, or17 migration-sensitive code.183. Keep state minimal: source state, derived state, and effects must each have a19 distinct reason to exist.204. Keep components readable at the call site. Prefer explicit props and event21 contracts over hidden module state.225. Preserve accessibility and keyboard behavior while changing markup.236. After edits, route to `svelte-verification` for autofix, checks, tests, and24 browser validation when applicable.2526## Implementation defaults2728- Match the project's TypeScript and formatting conventions.29- Keep SSR compatibility unless the component is intentionally browser-only.30- Use keyed lists when identity matters.31- Avoid broad reactive effects for simple derivations.32- Keep DOM reads, browser APIs, timers, and subscriptions contained and cleaned33 up.34- Use CSS custom properties or component-scoped styles for local theming; do not35 introduce a design system unless the task requires it.36- Keep errors, loading, empty, and disabled states visible in the implementation37 when the user flow needs them.3839## Read the relevant reference4041| Reference | Read when |42| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |43| [svelte-5-components.md](references/svelte-5-components.md) | Writing or reviewing runes, props, derived values, snippets, events, bindings, or component modules. |44| [component-review.md](references/component-review.md) | Checking accessibility, SSR behavior, performance, and maintainability before finalizing component code. |4546If the code depends on behavior that the local project or MCP docs do not prove,47state the uncertainty and verify before broadening the change.
nerymurillohnd