סקיל shadcn: ניהול קומפוננטות shadcn/ui בעבודה עם קלוד
shadcn הוא הסקיל הרשמי של פרויקט shadcn/ui לקלוד קוד. הסקיל מאפשר לקלוד להוסיף, לחפש, לתקן ולהרכיב קומפוננטות UI מתוך מאגרי shadcn והקהילה — ועושה זאת תוך שמירה על הכללים הקפדניים של הספרייה: קומפוזיציה לפני קוד מותאם, סמנטיקה לפני סגנון, ושימוש ב-design tokens במקום בערכים גולמיים. התוצאה: קוד UI עקבי, נגיש ואחיד, גם כשעובדים בצוות שלם של מפתחים מול קלוד. בסקירה זו אבחן את הסקיל לעומק, אציג את הכללים האכיפים, ואדגים מקרי שימוש מהפרקטיקה.
פקודת התקנה
npx shadcn@latest init
קובץ הסקיל הוא Markdown פתוח. אפשר להוריד אותו ולהריץ בדיקת קוד לפני התקנה דרך הכפתורים שבראש העמוד.
מה הסקיל כולל?
הסקיל מטמיע בקלוד קוד הקשר חי של פרויקט shadcn — אילו קומפוננטות מותקנות, מה ההגדרות, ואילו רישומים פעילים. בנוסף, הוא אוכף ארבעה עקרונות מרכזיים וכללים אכיפים על כל קוד UI שקלוד כותב, כדי לשמור על אחידות ונגישות.
קוד הסקיל המלא
---
name: shadcn
description: Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset".
user-invocable: false
allowed-tools: Bash(npx shadcn@latest *), Bash(pnpm dlx shadcn@latest *), Bash(bunx --bun shadcn@latest *)
---
# shadcn/ui
A framework for building ui, components and design systems. Components are added as source code to the user's project via the CLI.
> **IMPORTANT:** Run all CLI commands using the project's package runner: `npx shadcn@latest`, `pnpm dlx shadcn@latest`, or `bunx --bun shadcn@latest` — based on the project's `packageManager`. Examples below use `npx shadcn@latest` but substitute the correct runner for the project.
## Current Project Context
```json
!`npx shadcn@latest info --json`
```
The JSON above contains the project config and installed components. Use `npx shadcn@latest docs <component>` to get documentation and example URLs for any component.
## Principles
1. **Use existing components first.** Use `npx shadcn@latest search` to check registries before writing custom UI. Check community registries too.
2. **Compose, don't reinvent.** Settings page = Tabs + Card + form controls. Dashboard = Sidebar + Card + Chart + Table.
3. **Use built-in variants before custom styles.** `variant="outline"`, `size="sm"`, etc.
4. **Use semantic colors.** `bg-primary`, `text-muted-foreground` — never raw values like `bg-blue-500`.
## Critical Rules
These rules are **always enforced**. Each links to a file with Incorrect/Correct code pairs.
### Styling & Tailwind → [styling.md](./rules/styling.md)
- **`className` for layout, not styling.** Never override component colors or typography.
- **No `space-x-*` or `space-y-*`.** Use `flex` with `gap-*`. For vertical stacks, `flex flex-col gap-*`.
- **Use `size-*` when width and height are equal.** `size-10` not `w-10 h-10`.
- **Use `truncate` shorthand.** Not `overflow-hidden text-ellipsis whitespace-nowrap`.
- **No manual `dark:` color overrides.** Use semantic tokens (`bg-background`, `text-muted-foreground`).
- **Use `cn()` for conditional classes.** Don't write manual template literal ternaries.
- **No manual `z-index` on overlay components.** Dialog, Sheet, Popover, etc. handle their own stacking.
### Forms & Inputs → [forms.md](./rules/forms.md)
- **Forms use `FieldGroup` + `Field`.** Never use raw `div` with `space-y-*` or `grid gap-*` for form layout.
- **`InputGroup` uses `InputGroupInput`/`InputGroupTextarea`.** Never raw `Input`/`Textarea` inside `InputGroup`.
- **Buttons inside inputs use `InputGroup` + `InputGroupAddon`.**
- **Option sets (2–7 choices) use `ToggleGroup`.** Don't loop `Button` with manual active state.
- **`FieldSet` + `FieldLegend` for grouping related checkboxes/radios.** Don't use a `div` with a heading.
- **Field validation uses `data-invalid` + `aria-invalid`.** `data-invalid` on `Field`, `aria-invalid` on the control. For disabled: `data-disabled` on `Field`, `disabled` on the control.
### Component Structure → [composition.md](./rules/composition.md)
- **Items always inside their Group.** `SelectItem` → `SelectGroup`. `DropdownMenuItem` → `DropdownMenuGroup`. `CommandItem` → `CommandGroup`.
- **Use `asChild` (radix) or `render` (base) for custom triggers.** Check `base` field from `npx shadcn@latest info`. → [base-vs-radix.md](./rules/base-vs-radix.md)
- **Dialog, Sheet, and Drawer always need a Title.** `DialogTitle`, `SheetTitle`, `DrawerTitle` required for accessibility. Use `className="sr-only"` if visually hidden.
- **Use full Card composition.** `CardHeader`/`CardTitle`/`CardDescription`/`CardContent`/`CardFooter`. Don't dump everything in `CardContent`.
- **Button has no `isPending`/`isLoading`.** Compose with `Spinner` + `data-icon` + `disabled`.
- **`TabsTrigger` must be inside `TabsList`.** Never render triggers directly in `Tabs`.
- **`Avatar` always needs `AvatarFallback`.** For when the image fails to load.
### Use Components, Not Custom Markup → [composition.md](./rules/composition.md)
- **Use existing components before custom markup.** Check if a component exists before writing a styled `div`.
- **Callouts use `Alert`.** Don't build custom styled divs.
- **Empty states use `Empty`.** Don't build custom empty state markup.
- **Toast via `sonner`.** Use `toast()` from `sonner`.
- **Use `Separator`** instead of `<hr>` or `<div className="border-t">`.
- **Use `Skeleton`** for loading placeholders. No custom `animate-pulse` divs.
- **Use `Badge`** instead of custom styled spans.
### Icons → [icons.md](./rules/icons.md)
- **Icons in `Button` use `data-icon`.** `data-icon="inline-start"` or `data-icon="inline-end"` on the icon.
- **No sizing classes on icons inside components.** Components handle icon sizing via CSS. No `size-4` or `w-4 h-4`.
- **Pass icons as objects, not string keys.** `icon={CheckIcon}`, not a string lookup.
### CLI
- **Never decode or fetch preset codes manually.** Pass them directly to `npx shadcn@latest apply --preset <code>` for existing projects, or `npx shadcn@latest init --preset <code>` when initializing.
## Key Patterns
These are the most common patterns that differentiate correct shadcn/ui code. For edge cases, see the linked rule files above.
```tsx
// Form layout: FieldGroup + Field, not div + Label.
<FieldGroup>
<Field>
<FieldLabel htmlFor="email">Email</FieldLabel>
<Input id="email" />
</Field>
</FieldGroup>
// Validation: data-invalid on Field, aria-invalid on the control.
<Field data-invalid>
<FieldLabel>Email</FieldLabel>
<Input aria-invalid />
<FieldDescription>Invalid email.</FieldDescription>
</Field>
// Icons in buttons: data-icon, no sizing classes.
<Button>
<SearchIcon data-icon="inline-start" />
Search
</Button>
// Spacing: gap-*, not space-y-*.
<div className="flex flex-col gap-4"> // correct
<div className="space-y-4"> // wrong
// Equal dimensions: size-*, not w-* h-*.
<Avatar className="size-10"> // correct
<Avatar className="w-10 h-10"> // wrong
// Status colors: Badge variants or semantic tokens, not raw colors.
<Badge variant="secondary">+20.1%</Badge> // correct
<span className="text-emerald-600">+20.1%</span> // wrong
```
## Component Selection
| Need | Use |
| -------------------------- | --------------------------------------------------------------------------------------------------- |
| Button/action | `Button` with appropriate variant |
| Form inputs | `Input`, `Select`, `Combobox`, `Switch`, `Checkbox`, `RadioGroup`, `Textarea`, `InputOTP`, `Slider` |
| Toggle between 2–5 options | `ToggleGroup` + `ToggleGroupItem` |
| Data display | `Table`, `Card`, `Badge`, `Avatar` |
| Navigation | `Sidebar`, `NavigationMenu`, `Breadcrumb`, `Tabs`, `Pagination` |
| Overlays | `Dialog` (modal), `Sheet` (side panel), `Drawer` (bottom sheet), `AlertDialog` (confirmation) |
| Feedback | `sonner` (toast), `Alert`, `Progress`, `Skeleton`, `Spinner` |
| Command palette | `Command` inside `Dialog` |
| Charts | `Chart` (wraps Recharts) |
| Layout | `Card`, `Separator`, `Resizable`, `ScrollArea`, `Accordion`, `Collapsible` |
| Empty states | `Empty` |
| Menus | `DropdownMenu`, `ContextMenu`, `Menubar` |
| Tooltips/info | `Tooltip`, `HoverCard`, `Popover` |
## Key Fields
The injected project context contains these key fields:
- **`aliases`** → use the actual alias prefix for imports (e.g. `@/`, `~/`), never hardcode.
- **`isRSC`** → when `true`, components using `useState`, `useEffect`, event handlers, or browser APIs need `"use client"` at the top of the file. Always reference this field when advising on the directive.
- **`tailwindVersion`** → `"v4"` uses `@theme inline` blocks; `"v3"` uses `tailwind.config.js`.
- **`tailwindCssFile`** → the global CSS file where custom CSS variables are defined. Always edit this file, never create a new one.
- **`style`** → component visual treatment (e.g. `nova`, `vega`).
- **`base`** → primitive library (`radix` or `base`). Affects component APIs and available props.
- **`iconLibrary`** → determines icon imports. Use `lucide-react` for `lucide`, `@tabler/icons-react` for `tabler`, etc. Never assume `lucide-react`.
- **`resolvedPaths`** → exact file-system destinations for components, utils, hooks, etc.
- **`framework`** → routing and file conventions (e.g. Next.js App Router vs Vite SPA).
- **`packageManager`** → use this for any non-shadcn dependency installs (e.g. `pnpm add date-fns` vs `npm install date-fns`).
See [cli.md — `info` command](./cli.md) for the full field reference.
## Component Docs, Examples, and Usage
Run `npx shadcn@latest docs <component>` to get the URLs for a component's documentation, examples, and API reference. Fetch these URLs to get the actual content.
```bash
npx shadcn@latest docs button dialog select
```
**When creating, fixing, debugging, or using a component, always run `npx shadcn@latest docs` and fetch the URLs first.** This ensures you're working with the correct API and usage patterns rather than guessing.
## Workflow
1. **Get project context** — already injected above. Run `npx shadcn@latest info` again if you need to refresh.
2. **Check installed components first** — before running `add`, always check the `components` list from project context or list the `resolvedPaths.ui` directory. Don't import components that haven't been added, and don't re-add ones already installed.
3. **Find components** — `npx shadcn@latest search`.
4. **Get docs and examples** — run `npx shadcn@latest docs <component>` to get URLs, then fetch them. Use `npx shadcn@latest view` to browse registry items you haven't installed. To preview changes to installed components, use `npx shadcn@latest add --diff`.
5. **Install or update** — `npx shadcn@latest add`. When updating existing components, use `--dry-run` and `--diff` to preview changes first (see [Updating Components](#updating-components) below).
6. **Fix imports in third-party components** — After adding components from community registries (e.g. `@bundui`, `@magicui`), check the added non-UI files for hardcoded import paths like `@/components/ui/...`. These won't match the project's actual aliases. Use `npx shadcn@latest info` to get the correct `ui` alias (e.g. `@workspace/ui/components`) and rewrite the imports accordingly. The CLI rewrites imports for its own UI files, but third-party registry components may use default paths that don't match the project.
7. **Review added components** — After adding a component or block from any registry, **always read the added files and verify they are correct**. Check for missing sub-components (e.g. `SelectItem` without `SelectGroup`), missing imports, incorrect composition, or violations of the [Critical Rules](#critical-rules). Also replace any icon imports with the project's `iconLibrary` from the project context (e.g. if the registry item uses `lucide-react` but the project uses `hugeicons`, swap the imports and icon names accordingly). Fix all issues before moving on.
8. **Registry must be explicit** — When the user asks to add a block or component, **do not guess the registry**. If no registry is specified (e.g. user says "add a login block" without specifying `@shadcn`, `@tailark`, etc.), ask which registry to use. Never default to a registry on behalf of the user.
9. **Switching presets** — Ask the user first: **overwrite**, **partial**, **merge**, or **skip**?
- **Overwrite**: `npx shadcn@latest apply --preset <code>`. Overwrites detected components, fonts, and CSS variables.
- **Partial**: `npx shadcn@latest apply --preset <code> --only theme,font`. Updates only the selected preset parts without reinstalling UI components. Supported values are `theme` and `font`; comma-separated combinations are allowed. `icon` is intentionally not supported, because icon changes may require full component reinstall and transforms.
- **Merge**: `npx shadcn@latest init --preset <code> --force --no-reinstall`, then run `npx shadcn@latest info` to list installed components, then for each installed component use `--dry-run` and `--diff` to [smart merge](#updating-components) it individually.
- **Skip**: `npx shadcn@latest init --preset <code> --force --no-reinstall`. Only updates config and CSS, leaves components as-is.
- **Important**: Always run preset commands inside the user's project directory. `apply` only works in an existing project with a `components.json` file. The CLI automatically preserves the current base (`base` vs `radix`) from `components.json`. If you must use a scratch/temp directory (e.g. for `--dry-run` comparisons), pass `--base <current-base>` explicitly — preset codes do not encode the base.
## Updating Components
When the user asks to update a component from upstream while keeping their local changes, use `--dry-run` and `--diff` to intelligently merge. **NEVER fetch raw files from GitHub manually — always use the CLI.**
1. Run `npx shadcn@latest add <component> --dry-run` to see all files that would be affected.
2. For each file, run `npx shadcn@latest add <component> --diff <file>` to see what changed upstream vs local.
3. Decide per file based on the diff:
- No local changes → safe to overwrite.
- Has local changes → read the local file, analyze the diff, and apply upstream updates while preserving local modifications.
- User says "just update everything" → use `--overwrite`, but confirm first.
4. **Never use `--overwrite` without the user's explicit approval.**
## Quick Reference
```bash
# Create a new project.
npx shadcn@latest init --name my-app --preset base-nova
npx shadcn@latest init --name my-app --preset a2r6bw --template vite
# Create a monorepo project.
npx shadcn@latest init --name my-app --preset base-nova --monorepo
npx shadcn@latest init --name my-app --preset base-nova --template next --monorepo
# Initialize existing project.
npx shadcn@latest init --preset base-nova
npx shadcn@latest init --defaults # shortcut: --template=next --preset=nova (base style implied)
# Apply a preset to an existing project.
npx shadcn@latest apply --preset a2r6bw
npx shadcn@latest apply a2r6bw
npx shadcn@latest apply --preset a2r6bw --only theme
npx shadcn@latest apply --preset a2r6bw --only font
npx shadcn@latest apply --preset a2r6bw --only theme,font
# Add components.
npx shadcn@latest add button card dialog
npx shadcn@latest add @magicui/shimmer-button
npx shadcn@latest add --all
# Preview changes before adding/updating.
npx shadcn@latest add button --dry-run
npx shadcn@latest add button --diff button.tsx
npx shadcn@latest add @acme/form --view button.tsx
# Search registries.
npx shadcn@latest search @shadcn -q "sidebar"
npx shadcn@latest search @tailark -q "stats"
# Get component docs and example URLs.
npx shadcn@latest docs button dialog select
# View registry item details (for items not yet installed).
npx shadcn@latest view @shadcn/button
```
**Named presets:** `nova`, `vega`, `maia`, `lyra`, `mira`, `luma`
**Templates:** `next`, `vite`, `start`, `react-router`, `astro` (all support `--monorepo`) and `laravel` (not supported for monorepo)
**Preset codes:** Version-prefixed base62 strings (e.g. `a2r6bw` or `b0`), from [ui.shadcn.com](https://ui.shadcn.com).
## Detailed References
- [rules/forms.md](./rules/forms.md) — FieldGroup, Field, InputGroup, ToggleGroup, FieldSet, validation states
- [rules/composition.md](./rules/composition.md) — Groups, overlays, Card, Tabs, Avatar, Alert, Empty, Toast, Separator, Skeleton, Badge, Button loading
- [rules/icons.md](./rules/icons.md) — data-icon, icon sizing, passing icons as objects
- [rules/styling.md](./rules/styling.md) — Semantic colors, variants, className, spacing, size, truncate, dark mode, cn(), z-index
- [rules/base-vs-radix.md](./rules/base-vs-radix.md) — asChild vs render, Select, ToggleGroup, Slider, Accordion
- [cli.md](./cli.md) — Commands, flags, presets, templates
- [customization.md](./customization.md) — Theming, CSS variables, extending components
מה זה סקיל shadcn ולמה הוא הסטנדרט בפרויקטי shadcn/ui?
shadcn הוא הסקיל הרשמי שפיתח Shad Cn (יוצר ספריית shadcn/ui) במיוחד לעבודה של קלוד קוד עם הספרייה. הוא לא מוסיף קוד למערכת — הוא משנה את האופן שבו קלוד חושב על הקוד שהוא כותב.
הבעיה שהסקיל פותר: shadcn/ui היא ספרייה עם הרבה קונבנציות עדינות שקל מאוד לעבור עליהן בלי לדעת. cn() לקלאסים תנאיים, FieldGroup לטפסים, data-icon לאייקונים בכפתורים, semantic tokens לצבעים. בלי הסקיל, קלוד נוטה לכתוב קוד שמתפקד אבל סוטה מהסטנדרט. עם הזמן, הקוד הופך להיות אוסף מקרי של החלטות סגנון שונות.
הפתרון של הסקיל הוא דו-שלבי: קודם, הוא מספק לקלוד הקשר חי של הפרויקט — אילו קומפוננטות מותקנות, מה ההגדרות, אילו רישומים זמינים. שנית, הוא אוכף רשימה של כללים אכיפים שכל קוד UI חייב לעמוד בהם, עם הפניה לדוגמאות נכונות מול שגויות לכל כלל.
הסקיל הזה משתלב מעולה עם סקיל frontend-design של Anthropic שמתחיל את העבודה עם עיצוב כללי, ועם סקיל brand-guidelines שאוכף ערכי מותג. כשהשלושה פעילים, צוות פיתוח שמשתמש בקלוד מקבל UI אחיד, נגיש ועומד בסטנדרט מהשורה הראשונה.
מה סקיל shadcn נותן לקלוד קוד?
הסקיל מטמיע בקלוד את התהליך של בניית UI איכותי לפי סטנדרט shadcn — מקומפוזיציה ועד פרטי המיקרו של איך כותבים קלאס תנאי. כל אחת מהיכולות הבאות נאכפת אוטומטית.
קומפוזיציה לפני קוד מותאם
הסקיל אוכף שימוש בקומפוננטות קיימות לפני כתיבת UI מותאם. דף הגדרות = Tabs + Card + form controls. דשבורד = Sidebar + Card + Chart + Table. כך הקוד קצר יותר, אחיד יותר, ונגיש יותר מטבעו, ובלי המצאה מחדש של דברים שכבר נפתרו.
חיפוש בכל הרישומים
לפני שקלוד כותב משהו, הסקיל מורה לו לחפש בכל הרישומים: shadcn הרשמי, magicui, tailark, וקהילות נוספות. הרבה פעמים יש כבר קומפוננטה מוכנה שמתאימה. החיפוש הזה חוסך שעות וגורם לקוד להישאר תואם לסטנדרט הספרייה.
כללים אכיפים על Styling
הסקיל מטמיע רשימת כללים שאסור לעבור עליהם: gap-* במקום space-y-*, size-* כשגובה ורוחב שווים, semantic tokens (bg-primary) במקום ערכים גולמיים (bg-blue-500), cn() לקלאסים תנאיים. התוצאה: קוד שעובד עם dark mode וסגנונות נוספים אוטומטית.
טפסים מובנים נכון
הסקיל אוכף שימוש ב-FieldGroup + Field במקום div+Label לטפסים, ו-InputGroup לכפתורים בתוך שדות. ולידציה משתמשת ב-data-invalid + aria-invalid לנגישות מלאה. כל שינוי קטן בטופס נשאר עקבי בכל הפרויקט בלי שצריך לזכור 12 כללים בעצמך.
בלי הסקיל, קלוד כותב UI שמתפקד אבל סוטה מהסטנדרט. עם הסקיל, הוא כותב כמו מפתח מנוסה של shadcn/ui.
למי הסקיל הזה מתאים?
צוותי פיתוח שמשתמשים ב-shadcn/ui יומיומית: סוכנויות, סטארטאפים וצוותי R&D שעובדים מול הספרייה ומשתמשים בקלוד יקבלו מהסקיל את הערך הגבוה ביותר. הוא מבטיח שכל מפתח כותב באותם הכללים, גם אם רק חלק מהצוות מכיר את כל ה-best practices של shadcn.
פרויקטים שעוברים מ-Material UI או Chakra ל-shadcn: מעבר בין ספריות UI הוא נקודת כשל קלאסית — מתחילים נכון ובסוף יש מיקס של כללים. הסקיל מצמצם את הסיכון על ידי אכיפת הסטנדרט החדש על כל קוד שקלוד כותב במהלך המעבר. פלאגין Superpowers שבחנתי בעבר מאפשר לטעון את הסקיל אוטומטית בכל סשן.
חברות שבונות component library פנימי על בסיס shadcn: מי שיוצר 10-20 קומפוננטות פנימיות בנוסף ל-shadcn מקבל מהסקיל אכיפה שהן יבנו לפי אותם עקרונות (composition, semantic tokens, data-icon). יחד עם סקיל skill-creator אפשר אפילו לבנות סקיל פנימי שיודע על הקומפוננטות הספציפיות.
מובילי טכנולוגיה שדורשים נגישות מלאה: shadcn/ui מובילה בנגישות בזכות שימוש ב-Radix מתחת. הסקיל מבטיח שגם הקוד שמסביב לקומפוננטות שומר על נגישות (Title ב-Dialog, Fallback ב-Avatar, aria-invalid בטפסים). תוצאה: ביקורות נגישות עוברות בקלות.
מי שלא מתאים: פרויקטים שאינם משתמשים ב-shadcn/ui או בעלי שכבת UI שונה לחלוטין. הסקיל ספציפי ל-shadcn ולא יכול לסייע מחוץ לסקופ הזה. למפרויקטים כאלה כדאי סקיל frontend-design הכללי.
איך סקיל shadcn עזר בפרויקטים אמיתיים
בניית דשבורד SaaS חדש בעזרת קלוד
צוות פיתוח התחיל מוצר SaaS חדש עם shadcn/ui. עם הסקיל פעיל, קלוד הציע מבנה מלא של דשבורד מתוך הקומפוננטות הקיימות (Sidebar + Card + Chart + Table) במקום לכתוב markup מותאם. הזמן לדשבורד ראשון שעובד: שעה ועשרים, במקום יום עבודה.
ריפקטור של מערכת טפסים מורכבת
פרויקט קיים עם 40 טפסים שונים שכל אחד נכתב בצורה אחרת. עם הסקיל, קלוד עבר טופס אחר טופס והמיר אותם ל-FieldGroup + Field עם data-invalid אחיד. תוצאה: קוד מצומצם ב-40%, נגישות מלאה בכל הטפסים, ופחות באגים בולידציה.
הוספת component library פנימי לחברה
חברה רצתה להרחיב את shadcn עם 12 קומפוננטות פנימיות בייחוד שלה. הסקיל הנחה את קלוד לבנות אותן בהתאם לאותם עקרונות (composition, semantic tokens, data-icon) כך שהן מורגשות כחלק טבעי של הספרייה. צוותים מקבילים יכולים לאמץ אותן ללא חיכוך.
תיקון בעיות נגישות במוצר ותיק
מוצר ותיק שעבר ביקורת נגישות נכשל בעשרות בדיקות (Dialog ללא Title, Avatar ללא Fallback, אייקונים בלי aria). הסקיל זיהה ותיקן את כל הסעיפים האלה אוטומטית כשקלוד עבר על הקבצים. סיום לעבודה שהוערכה בשבועיים: שלושה ימים בלבד.
ארבעת המקרים האלה ממחישים שהסקיל מתאים גם לפרויקטים חדשים, גם לריפקטורים, גם לבניית ספריות פנימיות, וגם לתיקון נגישות. הזמן שמתחסך אצל המפתחים מצדיק את ההתקנה מיידית.
סיכום
shadcn הוא לא סתם סקיל — הוא הסטנדרט הרשמי שמומלץ לכל פרויקט שעובד עם shadcn/ui ומשתמש בקלוד קוד. הוא הופך את כתיבת ה-UI לעקבית, נגישה, ומיושמת בכללי הספרייה.
אם אתם בונים מוצר עם shadcn/ui, ההתקנה לוקחת שתי דקות וההשפעה היא יומית. כל קומפוננטה שקלוד יוסיף תיבנה לפי הכללים, וכל שינוי שהוא יציע יעבור את אותה אכיפה.
בסקירות הבאות אבחן עוד סקילים לעבודה עם UI ועיצוב מקצה לקצה. לצוותים שבונים מוצרים מורכבים מול shadcn/ui ומשתמשים בקלוד, הסקיל הזה הוא ההכרעה שהופכת UI מבולגן ל-UI סטנדרטי.
שיתוף הסקיל
שאלות ותשובות
מה הקשר בין הסקיל לקומפוננטות הקיימות בפרויקט?
הסקיל מריץ ברקע את `npx shadcn@latest info –json` כדי לקבל הקשר מלא: אילו קומפוננטות מותקנות, איך מוגדר components.json, אילו רישומים פעילים, ואיזה preset נבחר. כך קלוד מציע פתרונות שמתאימים בדיוק לפרויקט הספציפי, לא תשובות גנריות.
האם הסקיל דורש פרויקט קיים של shadcn?
כן, פעולתו מותנית בקובץ components.json (סימן לפרויקט shadcn). אם אין כזה, הוא יציע להריץ `npx shadcn@latest init` או להריץ אתחול עם preset. בלי הקובץ הוא לא מציע ניהול קומפוננטות, רק עזרה כללית.
מה ההבדל בין הסקיל הזה לסקיל frontend-design?
frontend-design מטפל בכל UI ומציע גישה כללית לעיצוב. shadcn מתמקד אך ורק בספריית shadcn/ui ובכלליה הספציפיים. אם הפרויקט שלך משתמש ב-shadcn, הסקיל הזה הרבה יותר מדויק. שניהם יכולים לעבוד יחד; shadcn יקבל עדיפות בכל שאלה ספציפית לקומפוננטה.
איך הסקיל מטפל ב-dark mode?
הוא אוכף שימוש ב-semantic tokens (bg-background, text-muted-foreground) במקום בצבעים גולמיים. כך כל קומפוננטה תומכת ב-dark mode אוטומטית בלי כתיבת dark: ידנית. אם אתה רואה dark: בקוד, סימן שחרגת מהכלל.
האם הסקיל עובד עם base ו-radix?
כן. הסקיל בודק את שדה `base` מ-info ומציע לקלוד להשתמש ב-`asChild` (radix) או `render` (base) בהתאם לבחירה בפרויקט. גם אכיפת ה-Title ב-Dialog ו-Sheet עובדת לשני העולמות באותה צורה.
מה לגבי אייקונים ומדידות?
הסקיל אוסר על קלאסי size-4 או w-4 h-4 על אייקונים בתוך קומפוננטות. הקומפוננטות מטפלות בגודל האייקון דרך CSS פנימי. בכפתורים עם אייקון, הסקיל אוכף שימוש ב-data-icon='inline-start' או 'inline-end' במקום סידור ידני.
האם הסקיל בודק שאני לא משתמש ב-Button isLoading?
כן. shadcn/ui החליטה במכוון שאין Button isPending או isLoading. הסקיל יעיר אם רואה ניסיון להשתמש בהם. במקום זאת, מרכיבים: Spinner + data-icon + disabled. זה נראה זהה אבל נשמרת קומפוזיציה אחידה.
האם אפשר לעבוד עם החבילה גם בלי הסקיל?
אפשר, אבל קלוד יפספס את ההקשר החי של הפרויקט וייצור הרבה יותר קוד מותאם שלא מתאים לסטנדרט. בעיקר בפרויקטים גדולים, הסקיל הוא ההבדל בין UI אחיד ל-UI מתחזק חצי-עקבי. ההמלצה: להתקין כל פעם שעובדים מול shadcn.