shadcn-sveltekit-design

分类: 商业与运营 | 上传者: Michael-Obele | 下载: 0 | 版本: v1.0（最新）

使用 shadcn-svelte、Bits UI 或 shadcn-svelte MCP 构建、重新设计、美化或重构 SvelteKit 页面和可重用组件时使用。在登陆页面、仪表板、营销网站、应用程序外壳、表单、导航栏、表格、对话框、响应式布局、主题、图标选择和请求上触发，将想法或粗略的模型转换为精美的 Svelte UI，而无需发明组件 API。

更新日志: Source: GitHub https://github.com/Michael-Obele/shadcn-svelte-mcp

目录结构

当前层级: tree/main/skills/shadcn-sveltekit-design/

📁 evals/
- 📄 evals.json 2.2 KB
📁 references/
- 📄 mcp-workflow.md 3.8 KB
- 📄 ui-rules.md 3.3 KB
📄 SKILL.md 4.6 KB

SKILL.md

---
name: shadcn-sveltekit-design
description: Use when building, redesigning, beautifying, or refactoring SvelteKit pages and reusable components with shadcn-svelte, Bits UI, or the shadcn-svelte MCP. Trigger on landing pages, dashboards, marketing sites, app shells, forms, navbars, tables, dialogs, responsive layouts, theming, icon selection, and requests to turn an idea or rough mockup into polished Svelte UI without inventing component APIs.
---

# Shadcn SvelteKit Design

Use this skill to create polished SvelteKit UI while grounding component decisions in the configured shadcn-svelte MCP instead of memory.

## 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

For page-level work, structure the response like this:

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

For reusable components, structure the response like this:

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

Read `references/ui-rules.md` when the task is about page design, visual refreshes, theming, or reusable UI.

## MCP Grounding

Read `references/mcp-workflow.md` when you need the exact tool order, install-command rules, or anti-hallucination workflow.

登录后下载/点赞/收藏 ❤ 44 | ★ 0

shadcn-sveltekit-design

目录结构

SKILL.md

举报内容

提示