Shadcn SvelteKit Design

Preconditions

• Expect these MCP tools to be available:

  shadcn-svelte-search

  ,

  shadcn-svelte-get

  ,

  shadcn-svelte-list

  ,

  shadcn-svelte-icons

  , and

  bits-ui-get

  .
• If the MCP is missing, say that clearly, help the user configure it, and avoid pretending a component or API exists.
• Treat

  shadcn-svelte-get

  as the source of truth for any component, block, chart, or docs page you plan to use.
• Treat official shadcn-svelte CLI installation as the default path for any library component that exists upstream.

Workflow

1. Understand the target before designing. Ask for the screen type, audience, content density, brand direction, and whether the work should preserve an existing visual language or introduce a new one.
2. Discover before composing. If the user describes a feature vaguely, start with

   references/mcp-workflow.md

   and use the discovery tools before writing UI code.
3. Commit to an intentional visual direction. Pick a clear design thesis instead of drifting into generic SaaS UI. Define typography, color logic, spacing, hierarchy, and motion up front.
4. Map the design to verified primitives. Build the layout from components, blocks, charts, docs, and icons that the MCP confirms are real. If the desired component is not available, say so and propose the closest verified alternative.
5. Write Svelte-first code. Output valid SvelteKit and Svelte 5 code. Never use React props, JSX patterns, or shadcn/ui React guidance.
6. Explain the chosen building blocks. Mention which components or docs were verified, especially when the user asks for implementation guidance or installation commands.
7. Install vendor components instead of reimplementing them. If a verified shadcn-svelte component exists, fetch the official CLI command from the MCP when possible and run it yourself when the task requires editing the project. Fall back to official shadcn-svelte documentation only when the MCP is unavailable. Do not hand-write the upstream component source from scratch. It is fine to write wrappers, compositions, page code, or project-specific variants around installed components.

Output Shape

1. A short design concept statement.
2. The verified shadcn-svelte building blocks you are using.
3. The SvelteKit file plan.
4. The implementation.

1. The component purpose and states.
2. The verified primitives or icons it depends on.
3. The public API or variants.
4. The implementation.

Guardrails

• Do not invent component names, CLI commands, or props.
• Do not recreate official shadcn-svelte component source by hand when the component can be installed with the CLI.
• Prefer retrieving CLI commands from the MCP before using web research.
• If you must research the CLI on the web, only trust commands from official shadcn-svelte documentation, not shadcn/ui or other similarly named libraries.
• Use

  shadcn-svelte-icons

  only for Lucide icons.
• Use

  bits-ui-get

  only when

  shadcn-svelte-get

  exposes

  tooling.bitsUi.exactName

  or

  docs.bitsuiName

  , and only for lower-level primitive details.
• When

  shadcn-svelte-get

  and

  bits-ui-get

  overlap, prefer

  shadcn-svelte-get

  for standard component usage and pass the exact primitive name into

  bits-ui-get

  only when you need underlying internals.
• Prefer a smaller set of verified components composed well over a wide, unverified grab bag.
• Preserve an existing design system when the user is working inside one.
• Keep desktop and mobile layouts intentional; do not treat mobile as an afterthought.
• If the user did not request a motion library and the project does not already use one, prefer Svelte's built-in

  transition:

  ,

  in:

  ,

  out:

  , and

  animate:

  capabilities.

Design Standards

references/ui-rules.md

MCP Grounding

references/mcp-workflow.md