name: svelte-code-writer description: Use Svelte MCP tools for documentation lookup and code validation. MUST be used whenever creating or editing any Svelte component (.svelte) or Svelte module (.svelte.ts/.svelte.js).
Svelte Code Writer
This skill provides access to official Svelte tooling via MCP (Model Context Protocol). Use these tools to ensure code correctness and access up-to-date documentation.
Available MCP Tools
You have direct access to these Svelte MCP tools. Call them as tools, NOT as bash commands.
1. List Documentation Sections
Tool: mcp__svelte__list-sections
Lists all available Svelte 5 and SvelteKit documentation sections. Each section includes use cases to help identify relevant docs.
When to use: Before looking up documentation, to find the right section names.
2. Get Documentation
Tool: mcp__svelte__get-documentation
Parameters:
section(required): Section name(s) to retrieve. Can be a single string or array of strings.
Examples:
section: "$state"
section: ["$state", "$derived", "$effect"]
section: "routing"
section: ["form-actions", "load"]
When to use:
- Unsure about Svelte 5 syntax
- Need to verify runes usage
- Looking up SvelteKit patterns (routing, load functions, etc.)
- Checking transition/animation APIs
3. Svelte Autofixer
Tool: mcp__svelte__svelte-autofixer
Analyzes Svelte code and returns suggestions to fix issues.
Parameters:
code(required): The Svelte component source codedesired_svelte_version(required): Use5for Svelte 5 projectsfilename(optional): Component filename (e.g., "Button.svelte")async(optional): Settrueif using async Svelte mode
When to use:
- After writing any Svelte component
- Before committing changes
- When debugging reactivity issues
- To catch Svelte 4 syntax in Svelte 5 projects
4. Playground Link Generator
Tool: mcp__svelte__playground-link
Generates a Svelte REPL playground link for code sharing.
Parameters:
name(required): Name for the playgroundtailwind(required): Settrueif code uses Tailwind CSSfiles(required): Object mapping filenames to content
Example:
{
"name": "Counter Example",
"tailwind": true,
"files": {
"App.svelte": "<script>let count = $state(0);</script>\n<button onclick={() => count++}>{count}</button>"
}
}
When to use:
- User asks to share or preview code
- Creating examples for documentation
- Debugging with minimal reproduction
Recommended Workflow
When Creating a New Component
- Check docs if needed: Use
list-sectionsthenget-documentationfor relevant topics - Write the component using Svelte 5 patterns
- Validate: Run
svelte-autofixeron the completed code - Fix any issues the autofixer identifies
- Re-validate until no issues remain
When Editing an Existing Component
- Read the file to understand current implementation
- Make changes using Svelte 5 syntax
- Validate: Run
svelte-autofixeron the updated code - Fix issues if any are found
When Debugging
- Run
svelte-autofixeron the problematic component - Check relevant docs with
get-documentation - Apply fixes based on suggestions
Common Documentation Lookups
| Task | Sections to Fetch |
|---|---|
| State management | $state, $derived, $effect |
| Component props | $props, $bindable |
| Routing | routing, load |
| Forms | form-actions, $app/forms |
| Transitions | transition:, svelte/transition |
| Lifecycle | $effect, lifecycle-hooks |
| SSR/SSG | page-options, adapter-static |
| Navigation state | $app/state, $app/navigation |
| Advanced state | svelte/reactivity, $state |
Tip: Use
mcp__svelte__list-sectionsfirst to see all available sections with their use cases, then fetch the relevant ones.
Important Notes
- Always use Svelte 5 syntax - This project uses runes (
$state,$props, etc.) - Always validate before finalizing - Run autofixer on every component
- These are MCP tools, not CLI commands - Call them directly as tools
- Check package.json for version - Read it to confirm Svelte version if uncertain
- Autofixer returns suggestions - Review and apply fixes manually, then re-run until clean
Mandatory Validation Workflow
BEFORE marking any Svelte task complete:
- Run
mcp__svelte__svelte-autofixerwith the full component code - Review suggestions returned
- Fix any issues identified
- Re-run autofixer until no issues remain
- Only THEN respond to the user
This is NOT optional. Skipping validation leads to broken code that frustrates users.