agent-skills

Reviews Svelte components for idiomatic patterns, identifies anti-patterns carried over from React/Vue/Svelte 4, and suggests Svelte 5 refactorings. Use when writing or reviewing Svelte components, asking "is this idiomatic", "Svelte way", doing Svelte 5 migration, or encountering smells like: effect assigns state, prop copied to $state, global store by default, $bindable everywhere, clickable div, createEventDispatcher, export let, on:click, slot-shaped APIs, lifecycle-driven code, imperative DOM wiring, immutable-update ceremony, context value replacement, shadcn-svelte form structure, Field.* components, bits-ui form controls, or component APIs that hide ownership. This is the general-purpose entry point for Svelte component review; delegates to sveltekit for routes/load/actions/server concerns and to focused references for details.

Mental-model reset for SvelteKit apps. Use when writing or reviewing routes, layouts, load functions, form actions, remote functions, hooks, auth, cookies, endpoints, redirects, errors, SSR, progressive enhancement, or app-level data flow. Triggers on SvelteKit, +page, +layout, +server, +page.server.ts, +layout.server.ts, hooks.server.ts, load, actions, fail(), redirect(), error(), cookies, locals, route groups, protected routes, sessions, form actions, enhance, remote functions, command(), query(), form(), getRequestEvent(), SSR, hydration, and serialization. Use svelte5 for component-level runes, snippets, accessibility, actions, transitions, and component API review.

General prose doctrine for anything a human will read — clear, concrete, free of ready-made phrases. Use when writing or editing documentation, explanations, summaries, commit messages, reports, or any other prose.

Use when authoring an agent skill that wraps a command-line tool — covers hands-on tool exploration, required vs. recommended sections, installation/usage structure, trigger-rich descriptions, task-grouped commands, progressive disclosure, and a pre-publish checklist. Triggers for CLI / command-line / terminal / shell-command tools and binary wrappers; for review, run the Checklist section.

Use when writing, reviewing, or rewriting user-facing error messages, validation messages, form errors, empty/error states, auth errors, failure notifications, retry/support copy, CLI errors, or API errors humans will read. Helps make errors specific, actionable, non-blaming, accessible, and safe without leaking sensitive details.

Write self-contained implementation plan files that a fresh, possibly weaker executor can run without the author's context — splitting work into PR-sized plans, with verification gates, STOP conditions, and a memo protocol for design forks. Use when asked to write/create a plan, turn a decided design or ticket into plans, or when another skill hands off plan-writing. Not for deciding what to build or executing plans.