[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H832CK1RCMQ9GV5FE13MWJ":3,"skill-same:01M6H832CK1RCMQ9GV5FE13MWJ":117},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":54,"linkOnly":55,"markdownContent":56,"markdownBody":57,"frontMatter":58,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":14,"repositoryHtmlUrl":64,"repositoryHomepageUrl":6,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M6H832CK1RCMQ9GV5FE13MWJ","tailwind-shadcn",null,"shadcn\u002Fui + Tailwind CSS standards. Auto-detects the framework — React uses the shadcn CLI with Base UI primitives, SolidJS uses shadcn-solid with Kobalte. TRIGGER — load BEFORE writing or editing any styling, not after: a `class=` or `className=` attribute is being added or changed; tailwind.config.*, globals.css, or anything under components\u002Fui\u002F is touched; the prompt names Tailwind, shadcn, a variant, a design token, a CSS variable, a responsive breakpoint, dark mode, or a colour; or an arbitrary bracket value like [24px] or [#1a1a1a] is about to be written. Trigger on plain requests — \"style this\", \"add a colour\", \"make this responsive\", \"match the other buttons\" — the user will not say \"Tailwind discipline\"; the class attribute is the trigger. SKIP only when no styling and no component file is touched.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53],"tailwind shadcn","shadcn","Tailwind","discipline","buttons","when","design token","mode","colour","token","styling","only","auto","design","Bash","config","component","react","components","css","cli","writing","2026-11-10 10:12:30",false,"---\nname: tailwind-shadcn\ndescription: >\n  shadcn\u002Fui + Tailwind CSS standards. Auto-detects the framework — React uses the shadcn CLI\n  with Base UI primitives, SolidJS uses shadcn-solid with Kobalte.\n  TRIGGER — load BEFORE writing or editing any styling, not after: a `class=` or `className=`\n  attribute is being added or changed; tailwind.config.*, globals.css, or anything under\n  components\u002Fui\u002F is touched; the prompt names Tailwind, shadcn, a variant, a design token, a\n  CSS variable, a responsive breakpoint, dark mode, or a colour; or an arbitrary bracket value\n  like [24px] or [#1a1a1a] is about to be written. Trigger on plain requests — \"style this\",\n  \"add a colour\", \"make this responsive\", \"match the other buttons\" — the user will not say\n  \"Tailwind discipline\"; the class attribute is the trigger.\n  SKIP only when no styling and no component file is touched.\nallowed-tools: Bash(npx shadcn@latest *), Bash(pnpm dlx shadcn@latest *), Bash(bunx --bun shadcn@latest *), Bash(npx shadcn-solid@latest *), Bash(pnpm dlx shadcn-solid@latest *), Bash(bunx --bun shadcn-solid@latest *)\n---\n\n# Tailwind + shadcn\u002Fui\n\nApply these patterns whether you're building new UI from scratch or refactoring existing code — the rules are the same either way.\n\n## Detect framework first\n\nThis skill serves two ecosystems. Before doing anything, read `package.json` to detect which one you're in:\n\n- **`react` \u002F `react-dom` present → React mode.** Primitive layer is **Base UI**; the CLI is the official **`npx shadcn@latest`**. Gather project context by running:\n  ```json\n  npx shadcn@latest info --json\n  ```\n  Key fields: `tailwindVersion` (v4 uses `@theme inline`; v3 uses `tailwind.config.js`), `tailwindCssFile` (always edit this file for CSS variables — never create a new one), `aliases` (use the actual alias prefix for imports, never hardcode), `base` (the primitive layer).\n- **`solid-js` present → Solid mode.** Primitive layer is **Kobalte** (Zaidan components); the CLI is **`npx shadcn-solid@latest`** (much thinner — no `info`\u002F`search`\u002F`docs`). Gather project context by reading `ui.config.json` + `package.json`. See [references\u002Fcli-shadcn-solid.md](.\u002Freferences\u002Fcli-shadcn-solid.md) and [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md).\n\n## Framework mode\n\n| Concern               | React mode                                                         | Solid mode                                                                                         |\n| --------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- |\n| Primitive layer       | Base UI — see \"Primitive layer APIs\" below                         | Kobalte (Zaidan) — see [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md)          |\n| CLI                   | `npx shadcn@latest` — see [references\u002Fcli.md](.\u002Freferences\u002Fcli.md) | `npx shadcn-solid@latest` — see [references\u002Fcli-shadcn-solid.md](.\u002Freferences\u002Fcli-shadcn-solid.md) |\n| JSX class attribute   | `className`                                                        | `class`                                                                                            |\n| Component composition | `asChild` + `Slot`                                                 | `\u003CDynamic>` \u002F Kobalte polymorphic `as`                                                             |\n| Lists                 | `.map(... key={})`                                                 | `\u003CFor each>` \u002F `\u003CIndex>`                                                                           |\n\n**Normalization note (Solid mode):** the styling discipline below and the shared references (`theming.md`, `responsive.md`, `cva.md`) use React (`className`) syntax in their examples. In Solid mode, **read every `className` as `class`**, read `.map(...)`+`key` as `\u003CFor each>`, and ignore React-only constructs (`React.*` types, `asChild`, `Slot`). See [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md) for the Solid equivalents. The Tailwind\u002Ftoken discipline itself is identical in both modes.\n\n---\n\n## Principles\n\n1. **Reusability first — exhaust existing options before writing any inline\u002Fcustom component.** Work down this ladder in order:\n   1. **Search what the project already has.** Scan the UI components directory (`resolvedPaths.ui` in React mode; the components dir in Solid mode) for an existing component that fits.\n   2. **Extend what exists.** If an existing component nearly fits and it makes semantic sense, reuse it. Add a new `cva` variant **only when the styling will be reused in more than one place** — for a one-off, prefer composition or a `className` override. Don't reach for a variant by default; overusing `cva` adds complexity. See [references\u002Fcva.md](.\u002Freferences\u002Fcva.md).\n   3. **Bring in an available component.** Check the registry before writing custom UI — `npx shadcn@latest search` (React); browse the shadcn-solid catalog (Solid, no `search`). Check community registries too.\n   4. **Only then write custom code**, and consult the component docs first (`npx shadcn@latest docs \u003Ccomponent>` in React mode) for the recommended reusable pattern.\n2. **Compose, don't reinvent.** Settings page = Tabs + Card + form controls. Dashboard = Sidebar + Card + Chart + Table.\n3. **Use built-in variants before custom styles.** `variant=\"outline\"`, `size=\"sm\"`, etc.\n4. **Use semantic colors.** `bg-primary`, `text-muted-foreground` — never raw values like `bg-blue-500`.\n\n---\n\n## Critical Rules\n\nThese rules are always enforced.\n\n### Colors\n\n- **Never** use raw Tailwind palette values (`text-blue-500`, `bg-emerald-600`) in application code.\n- **Never** hardcode hex\u002Frgb\u002Foklch values inline in className strings.\n- **Use semantic tokens** for all color decisions: `bg-primary`, `text-destructive`, `border-border`.\n- For status indicators with no matching token, use `Badge` variants first. If a reusable semantic token is needed (e.g. `--success`), add it to the theme.\n\n### Spacing & layout\n\n- **No `space-x-*` or `space-y-*`.** Use `flex` + `gap-*` instead. `space-y-4` → `flex flex-col gap-4`.\n- **`size-*` when width = height.** `size-10` not `w-10 h-10`.\n- **`truncate`** not `overflow-hidden text-ellipsis whitespace-nowrap`.\n\n### Component styling\n\n- **`className` is for layout, not overrides.** Acceptable: `max-w-md mx-auto mt-4`. Not acceptable: `bg-blue-100 text-blue-900 font-bold`.\n- **Built-in variants first.** Exhaust `variant=\"outline\"`, `variant=\"destructive\"`, `size=\"sm\"` before adding new ones.\n- **Add a new variant sparingly** — only when a styling pattern repeats (used in more than one place) and no built-in fits. Edit the component source using `cva`. Not every component needs variants; a one-off doesn't warrant one. See [references\u002Fcva.md](.\u002Freferences\u002Fcva.md).\n\n### Class merging\n\n- **`cn()` for all conditional or merged classes.** No `${isActive ? 'bg-primary' : 'bg-muted'}` in className.\n- **No manual `z-index`** on overlay components (Dialog, Sheet, Popover, Tooltip, Drawer). They manage their own stacking.\n- **No manual `dark:` overrides.** Semantic tokens handle theme switching via CSS variables.\n\n---\n\n## CSS Architecture\n\n### Variables at `:root`\n\nAll color tokens are CSS custom properties on `:root` in the global CSS file (`tailwindCssFile` from project context). Never scatter variable definitions across component files.\n\n```css\n:root {\n  --background: oklch(1 0 0);\n  --foreground: oklch(0.145 0 0);\n  --primary: oklch(0.205 0 0);\n  --primary-foreground: oklch(0.985 0 0);\n  --muted: oklch(0.97 0 0);\n  --muted-foreground: oklch(0.556 0 0);\n  \u002F* ... see references\u002Ftheming.md for the full token set *\u002F\n}\n```\n\n**OKLCH:** `oklch(lightness chroma hue)` — perceptually uniform, so equal chroma values look equally saturated across hues. Prefer it over HSL.\n\n### Map variables to Tailwind\n\nWith **Tailwind v4**, register every CSS variable via `@theme inline`:\n\n```css\n@theme inline {\n  --color-background: var(--background);\n  --color-foreground: var(--foreground);\n  --color-primary: var(--primary);\n  --color-primary-foreground: var(--primary-foreground);\n  \u002F* ... see references\u002Ftheming.md for the full mapping *\u002F\n  --radius-sm: calc(var(--radius) - 4px);\n  --radius-md: calc(var(--radius) - 2px);\n  --radius-lg: var(--radius);\n  --radius-xl: calc(var(--radius) + 4px);\n}\n```\n\n### Apply base styles\n\n```css\n@layer base {\n  * {\n    @apply border-border;\n  }\n  body {\n    @apply bg-background text-foreground;\n  }\n}\n```\n\nDo not double-wrap: inside `@layer` blocks, use utility classes (`bg-background`) or `var(--background)` directly — never `oklch(var(--background))`.\n\n---\n\n## Adding Theme Tokens\n\nBefore reaching for an arbitrary value or a raw Tailwind color:\n\n```\nNeed a color or spacing unit →\n  Does a semantic token cover it?            → use it\n  Does a Tailwind default utility cover it?  → use it\n  Is this a one-off pixel nudge?             → arbitrary is fine: [3px]\n  Will this value appear in more than once?  → add a token\n```\n\nSee [references\u002Ftheming.md](.\u002Freferences\u002Ftheming.md) for the full custom color and spacing token workflow, naming conventions, and the complete token table.\n\n---\n\n## Components & CLI\n\n> Run all CLI commands with the project's package runner (`npx` \u002F `pnpm dlx` \u002F `bunx --bun`) — from `packageManager` in project context.\n\n### React mode\n\n```bash\nnpx shadcn@latest add button card dialog\nnpx shadcn@latest add @magicui\u002Fshimmer-button   # from a community registry\n```\n\n**Preview before installing** with `--dry-run` \u002F `--diff` — see [references\u002Fcli.md](.\u002Freferences\u002Fcli.md). Full registry surface available: `search`, `docs`, `info`.\n\n### Solid mode\n\n```bash\nnpx shadcn-solid@latest add button card dialog\n```\n\nThe shadcn-solid CLI is thin — **only `init`, `add`, and `diff`**. There is **no** `info`, `search`, `docs`, `--dry-run`, or `--diff`\u002F`--view` flag. Browse component docs at zaidan.carere.dev \u002F shadcn-solid.com in the browser instead, and preview changes via the `diff` command or by reading the copy-paste source. See [references\u002Fcli-shadcn-solid.md](.\u002Freferences\u002Fcli-shadcn-solid.md).\n\n**After adding (either mode), always read the added files** and verify correct composition: check for missing sub-components, incorrect nesting, and violations of the Critical Rules above. In Solid mode, also apply the bundle-weight check from [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md) — trim or hand-roll components that pull Kobalte for no a11y benefit.\n\n### Primitive layer APIs\n\n**React mode — Base UI.** Key differences from Radix to keep in mind:\n\n- **Composition:** use the `render` prop, not `asChild`. `\u003CDialogTrigger render={\u003CButton \u002F>}>Open\u003C\u002FDialogTrigger>`\n- **Select:** requires an `items` prop on the root; `defaultValue` for placeholder is `null` in the items array.\n- **ToggleGroup \u002F Accordion:** use `multiple` boolean instead of `type=\"multiple\"`; `defaultValue` is always an array.\n- **Slider:** accepts a plain number for a single thumb (`defaultValue={50}`), not an array.\n\n**Solid mode — Kobalte.** The primitive APIs, composition (`as` prop), and the bundle-weight discipline that governs _when_ to reach for a Kobalte primitive at all are covered in [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md). Read it before adding any interactive Solid component.\n\n---\n\n## Workflow\n\n1. **Detect framework & get project context** — read `package.json` (React vs Solid), then gather context per \"Detect framework first\" above (React: `npx shadcn@latest info --json`; Solid: read `ui.config.json` + `package.json`).\n2. **Check installed components first** — before running `add`, check what's already in the UI directory (`resolvedPaths.ui` in React; the components dir from `ui.config.json` in Solid). Don't import components that haven't been added, and don't re-add ones already installed.\n3. **Find the component** —\n   - _React:_ `npx shadcn@latest search` to discover components (community registries too).\n   - _Solid:_ no `search` — browse zaidan.carere.dev \u002F shadcn-solid.com in the browser.\n4. **Get docs and examples** —\n   - _React:_ `npx shadcn@latest docs \u003Ccomponent>` for URLs, then fetch; use `--dry-run` \u002F `--diff` to preview.\n   - _Solid:_ no `docs`\u002Fpreview flags — read the docs site, and preview via `diff` or by reading the copy-paste source after `add`.\n5. **Install** — `npx shadcn@latest add \u003Ccomponent>` (React) or `npx shadcn-solid@latest add \u003Ccomponent>` (Solid).\n6. **Review added files** — read every added file; fix composition issues, icon imports, and alias paths. _Solid:_ also run the bundle-weight check ([references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md)) — hand-roll or trim components that pull Kobalte without an a11y payoff.\n7. **Apply styling rules** — use semantic tokens, `cn()`, the `cva` variant pattern, and mobile-first responsive styles per the Critical Rules above.\n8. **Format & lint** — detect the project formatter from `package.json` scripts and run it on every changed file. A non-zero exit is a blocking failure — do not declare the task done until it passes. See [references\u002Fformatting.md](.\u002Freferences\u002Fformatting.md) for the detection heuristic and per-tool commands.\n\n---\n\n## CVA vs cn\n\nSee [references\u002Fcva.md](.\u002Freferences\u002Fcva.md) for the full guide.\n\n**Quick rule:**\n\n- `cva` lives in component definitions — it encodes what variants a component supports.\n- `cn` lives at call sites — it merges incoming `className` with cva output and handles conditionals.\n\n```tsx\nconst buttonVariants = cva(\"inline-flex items-center ...\", {\n  variants: { variant: { default: \"bg-primary ...\", outline: \"border ...\" } },\n  defaultVariants: { variant: \"default\" },\n});\n\nfunction Button({ className, variant, ...props }) {\n  return (\n    \u003Cbutton className={cn(buttonVariants({ variant }), className)} {...props} \u002F>\n  );\n}\n```\n\n---\n\n## Responsive Design\n\nSee [references\u002Fresponsive.md](.\u002Freferences\u002Fresponsive.md) for breakpoint reference and patterns.\n\n**Key rules:**\n\n- Write **base (mobile) styles first**, then layer breakpoint modifiers upward: `sm:`, `md:`, `lg:`.\n- **Flex by default.** `flex flex-col` for vertical stacks, `flex` for horizontal.\n- **Grid only when genuinely two-dimensional** — real rows _and_ columns (data tables, calendar grids). Never use grid as a substitute for flex on a single axis.\n\n```tsx\n\u002F\u002F Good: flex column on mobile, row on desktop\n\u003Cdiv className=\"flex flex-col gap-4 md:flex-row md:items-center\">\n```\n\n---\n\n## References\n\n**Shared (both modes):**\n\n- [references\u002Ftheming.md](.\u002Freferences\u002Ftheming.md) — Full OKLCH token table, `@theme inline` mapping, adding custom tokens\n- [references\u002Fcva.md](.\u002Freferences\u002Fcva.md) — `cva` vs `cn`, variant patterns, compound variants\n- [references\u002Fresponsive.md](.\u002Freferences\u002Fresponsive.md) — Breakpoints, flex\u002Fgrid decision guide, common responsive patterns\n\n**React mode:**\n\n- [references\u002Fcli.md](.\u002Freferences\u002Fcli.md) — `npx shadcn@latest`: adding, previewing, searching registries, docs, project info\n\n**Solid mode:**\n\n- [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md) — Kobalte\u002FZaidan authoring idioms, primitive APIs, and the bundle-weight selective-adoption discipline\n- [references\u002Fcli-shadcn-solid.md](.\u002Freferences\u002Fcli-shadcn-solid.md) — `npx shadcn-solid@latest`: the thin CLI surface, Zaidan delivery, browser-docs workflow\n\n**Tooling:**\n\n- [references\u002Fformatting.md](.\u002Freferences\u002Fformatting.md) — Formatter detection heuristic and per-tool commands (Biome, Prettier+ESLint, ESLint-only)\n","# Tailwind + shadcn\u002Fui\n\nApply these patterns whether you're building new UI from scratch or refactoring existing code — the rules are the same either way.\n\n## Detect framework first\n\nThis skill serves two ecosystems. Before doing anything, read `package.json` to detect which one you're in:\n\n- **`react` \u002F `react-dom` present → React mode.** Primitive layer is **Base UI**; the CLI is the official **`npx shadcn@latest`**. Gather project context by running:\n  ```json\n  npx shadcn@latest info --json\n  ```\n  Key fields: `tailwindVersion` (v4 uses `@theme inline`; v3 uses `tailwind.config.js`), `tailwindCssFile` (always edit this file for CSS variables — never create a new one), `aliases` (use the actual alias prefix for imports, never hardcode), `base` (the primitive layer).\n- **`solid-js` present → Solid mode.** Primitive layer is **Kobalte** (Zaidan components); the CLI is **`npx shadcn-solid@latest`** (much thinner — no `info`\u002F`search`\u002F`docs`). Gather project context by reading `ui.config.json` + `package.json`. See [references\u002Fcli-shadcn-solid.md](.\u002Freferences\u002Fcli-shadcn-solid.md) and [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md).\n\n## Framework mode\n\n| Concern               | React mode                                                         | Solid mode                                                                                         |\n| --------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- |\n| Primitive layer       | Base UI — see \"Primitive layer APIs\" below                         | Kobalte (Zaidan) — see [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md)          |\n| CLI                   | `npx shadcn@latest` — see [references\u002Fcli.md](.\u002Freferences\u002Fcli.md) | `npx shadcn-solid@latest` — see [references\u002Fcli-shadcn-solid.md](.\u002Freferences\u002Fcli-shadcn-solid.md) |\n| JSX class attribute   | `className`                                                        | `class`                                                                                            |\n| Component composition | `asChild` + `Slot`                                                 | `\u003CDynamic>` \u002F Kobalte polymorphic `as`                                                             |\n| Lists                 | `.map(... key={})`                                                 | `\u003CFor each>` \u002F `\u003CIndex>`                                                                           |\n\n**Normalization note (Solid mode):** the styling discipline below and the shared references (`theming.md`, `responsive.md`, `cva.md`) use React (`className`) syntax in their examples. In Solid mode, **read every `className` as `class`**, read `.map(...)`+`key` as `\u003CFor each>`, and ignore React-only constructs (`React.*` types, `asChild`, `Slot`). See [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md) for the Solid equivalents. The Tailwind\u002Ftoken discipline itself is identical in both modes.\n\n---\n\n## Principles\n\n1. **Reusability first — exhaust existing options before writing any inline\u002Fcustom component.** Work down this ladder in order:\n   1. **Search what the project already has.** Scan the UI components directory (`resolvedPaths.ui` in React mode; the components dir in Solid mode) for an existing component that fits.\n   2. **Extend what exists.** If an existing component nearly fits and it makes semantic sense, reuse it. Add a new `cva` variant **only when the styling will be reused in more than one place** — for a one-off, prefer composition or a `className` override. Don't reach for a variant by default; overusing `cva` adds complexity. See [references\u002Fcva.md](.\u002Freferences\u002Fcva.md).\n   3. **Bring in an available component.** Check the registry before writing custom UI — `npx shadcn@latest search` (React); browse the shadcn-solid catalog (Solid, no `search`). Check community registries too.\n   4. **Only then write custom code**, and consult the component docs first (`npx shadcn@latest docs \u003Ccomponent>` in React mode) for the recommended reusable pattern.\n2. **Compose, don't reinvent.** Settings page = Tabs + Card + form controls. Dashboard = Sidebar + Card + Chart + Table.\n3. **Use built-in variants before custom styles.** `variant=\"outline\"`, `size=\"sm\"`, etc.\n4. **Use semantic colors.** `bg-primary`, `text-muted-foreground` — never raw values like `bg-blue-500`.\n\n---\n\n## Critical Rules\n\nThese rules are always enforced.\n\n### Colors\n\n- **Never** use raw Tailwind palette values (`text-blue-500`, `bg-emerald-600`) in application code.\n- **Never** hardcode hex\u002Frgb\u002Foklch values inline in className strings.\n- **Use semantic tokens** for all color decisions: `bg-primary`, `text-destructive`, `border-border`.\n- For status indicators with no matching token, use `Badge` variants first. If a reusable semantic token is needed (e.g. `--success`), add it to the theme.\n\n### Spacing & layout\n\n- **No `space-x-*` or `space-y-*`.** Use `flex` + `gap-*` instead. `space-y-4` → `flex flex-col gap-4`.\n- **`size-*` when width = height.** `size-10` not `w-10 h-10`.\n- **`truncate`** not `overflow-hidden text-ellipsis whitespace-nowrap`.\n\n### Component styling\n\n- **`className` is for layout, not overrides.** Acceptable: `max-w-md mx-auto mt-4`. Not acceptable: `bg-blue-100 text-blue-900 font-bold`.\n- **Built-in variants first.** Exhaust `variant=\"outline\"`, `variant=\"destructive\"`, `size=\"sm\"` before adding new ones.\n- **Add a new variant sparingly** — only when a styling pattern repeats (used in more than one place) and no built-in fits. Edit the component source using `cva`. Not every component needs variants; a one-off doesn't warrant one. See [references\u002Fcva.md](.\u002Freferences\u002Fcva.md).\n\n### Class merging\n\n- **`cn()` for all conditional or merged classes.** No `${isActive ? 'bg-primary' : 'bg-muted'}` in className.\n- **No manual `z-index`** on overlay components (Dialog, Sheet, Popover, Tooltip, Drawer). They manage their own stacking.\n- **No manual `dark:` overrides.** Semantic tokens handle theme switching via CSS variables.\n\n---\n\n## CSS Architecture\n\n### Variables at `:root`\n\nAll color tokens are CSS custom properties on `:root` in the global CSS file (`tailwindCssFile` from project context). Never scatter variable definitions across component files.\n\n```css\n:root {\n  --background: oklch(1 0 0);\n  --foreground: oklch(0.145 0 0);\n  --primary: oklch(0.205 0 0);\n  --primary-foreground: oklch(0.985 0 0);\n  --muted: oklch(0.97 0 0);\n  --muted-foreground: oklch(0.556 0 0);\n  \u002F* ... see references\u002Ftheming.md for the full token set *\u002F\n}\n```\n\n**OKLCH:** `oklch(lightness chroma hue)` — perceptually uniform, so equal chroma values look equally saturated across hues. Prefer it over HSL.\n\n### Map variables to Tailwind\n\nWith **Tailwind v4**, register every CSS variable via `@theme inline`:\n\n```css\n@theme inline {\n  --color-background: var(--background);\n  --color-foreground: var(--foreground);\n  --color-primary: var(--primary);\n  --color-primary-foreground: var(--primary-foreground);\n  \u002F* ... see references\u002Ftheming.md for the full mapping *\u002F\n  --radius-sm: calc(var(--radius) - 4px);\n  --radius-md: calc(var(--radius) - 2px);\n  --radius-lg: var(--radius);\n  --radius-xl: calc(var(--radius) + 4px);\n}\n```\n\n### Apply base styles\n\n```css\n@layer base {\n  * {\n    @apply border-border;\n  }\n  body {\n    @apply bg-background text-foreground;\n  }\n}\n```\n\nDo not double-wrap: inside `@layer` blocks, use utility classes (`bg-background`) or `var(--background)` directly — never `oklch(var(--background))`.\n\n---\n\n## Adding Theme Tokens\n\nBefore reaching for an arbitrary value or a raw Tailwind color:\n\n```\nNeed a color or spacing unit →\n  Does a semantic token cover it?            → use it\n  Does a Tailwind default utility cover it?  → use it\n  Is this a one-off pixel nudge?             → arbitrary is fine: [3px]\n  Will this value appear in more than once?  → add a token\n```\n\nSee [references\u002Ftheming.md](.\u002Freferences\u002Ftheming.md) for the full custom color and spacing token workflow, naming conventions, and the complete token table.\n\n---\n\n## Components & CLI\n\n> Run all CLI commands with the project's package runner (`npx` \u002F `pnpm dlx` \u002F `bunx --bun`) — from `packageManager` in project context.\n\n### React mode\n\n```bash\nnpx shadcn@latest add button card dialog\nnpx shadcn@latest add @magicui\u002Fshimmer-button   # from a community registry\n```\n\n**Preview before installing** with `--dry-run` \u002F `--diff` — see [references\u002Fcli.md](.\u002Freferences\u002Fcli.md). Full registry surface available: `search`, `docs`, `info`.\n\n### Solid mode\n\n```bash\nnpx shadcn-solid@latest add button card dialog\n```\n\nThe shadcn-solid CLI is thin — **only `init`, `add`, and `diff`**. There is **no** `info`, `search`, `docs`, `--dry-run`, or `--diff`\u002F`--view` flag. Browse component docs at zaidan.carere.dev \u002F shadcn-solid.com in the browser instead, and preview changes via the `diff` command or by reading the copy-paste source. See [references\u002Fcli-shadcn-solid.md](.\u002Freferences\u002Fcli-shadcn-solid.md).\n\n**After adding (either mode), always read the added files** and verify correct composition: check for missing sub-components, incorrect nesting, and violations of the Critical Rules above. In Solid mode, also apply the bundle-weight check from [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md) — trim or hand-roll components that pull Kobalte for no a11y benefit.\n\n### Primitive layer APIs\n\n**React mode — Base UI.** Key differences from Radix to keep in mind:\n\n- **Composition:** use the `render` prop, not `asChild`. `\u003CDialogTrigger render={\u003CButton \u002F>}>Open\u003C\u002FDialogTrigger>`\n- **Select:** requires an `items` prop on the root; `defaultValue` for placeholder is `null` in the items array.\n- **ToggleGroup \u002F Accordion:** use `multiple` boolean instead of `type=\"multiple\"`; `defaultValue` is always an array.\n- **Slider:** accepts a plain number for a single thumb (`defaultValue={50}`), not an array.\n\n**Solid mode — Kobalte.** The primitive APIs, composition (`as` prop), and the bundle-weight discipline that governs _when_ to reach for a Kobalte primitive at all are covered in [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md). Read it before adding any interactive Solid component.\n\n---\n\n## Workflow\n\n1. **Detect framework & get project context** — read `package.json` (React vs Solid), then gather context per \"Detect framework first\" above (React: `npx shadcn@latest info --json`; Solid: read `ui.config.json` + `package.json`).\n2. **Check installed components first** — before running `add`, check what's already in the UI directory (`resolvedPaths.ui` in React; the components dir from `ui.config.json` in Solid). Don't import components that haven't been added, and don't re-add ones already installed.\n3. **Find the component** —\n   - _React:_ `npx shadcn@latest search` to discover components (community registries too).\n   - _Solid:_ no `search` — browse zaidan.carere.dev \u002F shadcn-solid.com in the browser.\n4. **Get docs and examples** —\n   - _React:_ `npx shadcn@latest docs \u003Ccomponent>` for URLs, then fetch; use `--dry-run` \u002F `--diff` to preview.\n   - _Solid:_ no `docs`\u002Fpreview flags — read the docs site, and preview via `diff` or by reading the copy-paste source after `add`.\n5. **Install** — `npx shadcn@latest add \u003Ccomponent>` (React) or `npx shadcn-solid@latest add \u003Ccomponent>` (Solid).\n6. **Review added files** — read every added file; fix composition issues, icon imports, and alias paths. _Solid:_ also run the bundle-weight check ([references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md)) — hand-roll or trim components that pull Kobalte without an a11y payoff.\n7. **Apply styling rules** — use semantic tokens, `cn()`, the `cva` variant pattern, and mobile-first responsive styles per the Critical Rules above.\n8. **Format & lint** — detect the project formatter from `package.json` scripts and run it on every changed file. A non-zero exit is a blocking failure — do not declare the task done until it passes. See [references\u002Fformatting.md](.\u002Freferences\u002Fformatting.md) for the detection heuristic and per-tool commands.\n\n---\n\n## CVA vs cn\n\nSee [references\u002Fcva.md](.\u002Freferences\u002Fcva.md) for the full guide.\n\n**Quick rule:**\n\n- `cva` lives in component definitions — it encodes what variants a component supports.\n- `cn` lives at call sites — it merges incoming `className` with cva output and handles conditionals.\n\n```tsx\nconst buttonVariants = cva(\"inline-flex items-center ...\", {\n  variants: { variant: { default: \"bg-primary ...\", outline: \"border ...\" } },\n  defaultVariants: { variant: \"default\" },\n});\n\nfunction Button({ className, variant, ...props }) {\n  return (\n    \u003Cbutton className={cn(buttonVariants({ variant }), className)} {...props} \u002F>\n  );\n}\n```\n\n---\n\n## Responsive Design\n\nSee [references\u002Fresponsive.md](.\u002Freferences\u002Fresponsive.md) for breakpoint reference and patterns.\n\n**Key rules:**\n\n- Write **base (mobile) styles first**, then layer breakpoint modifiers upward: `sm:`, `md:`, `lg:`.\n- **Flex by default.** `flex flex-col` for vertical stacks, `flex` for horizontal.\n- **Grid only when genuinely two-dimensional** — real rows _and_ columns (data tables, calendar grids). Never use grid as a substitute for flex on a single axis.\n\n```tsx\n\u002F\u002F Good: flex column on mobile, row on desktop\n\u003Cdiv className=\"flex flex-col gap-4 md:flex-row md:items-center\">\n```\n\n---\n\n## References\n\n**Shared (both modes):**\n\n- [references\u002Ftheming.md](.\u002Freferences\u002Ftheming.md) — Full OKLCH token table, `@theme inline` mapping, adding custom tokens\n- [references\u002Fcva.md](.\u002Freferences\u002Fcva.md) — `cva` vs `cn`, variant patterns, compound variants\n- [references\u002Fresponsive.md](.\u002Freferences\u002Fresponsive.md) — Breakpoints, flex\u002Fgrid decision guide, common responsive patterns\n\n**React mode:**\n\n- [references\u002Fcli.md](.\u002Freferences\u002Fcli.md) — `npx shadcn@latest`: adding, previewing, searching registries, docs, project info\n\n**Solid mode:**\n\n- [references\u002Fprimitives-solid.md](.\u002Freferences\u002Fprimitives-solid.md) — Kobalte\u002FZaidan authoring idioms, primitive APIs, and the bundle-weight selective-adoption discipline\n- [references\u002Fcli-shadcn-solid.md](.\u002Freferences\u002Fcli-shadcn-solid.md) — `npx shadcn-solid@latest`: the thin CLI surface, Zaidan delivery, browser-docs workflow\n\n**Tooling:**\n\n- [references\u002Fformatting.md](.\u002Freferences\u002Fformatting.md) — Formatter detection heuristic and per-tool commands (Biome, Prettier+ESLint, ESLint-only)\n",{"name":5,"description":59,"allowed-tools":60},"shadcn\u002Fui + Tailwind CSS standards. Auto-detects the framework — React uses the shadcn CLI with Base UI primitives, SolidJS uses shadcn-solid with Kobalte. TRIGGER — load BEFORE writing or editing any styling, not after: a `class=` or `className=` attribute is being added or changed; tailwind.config.*, globals.css, or anything under components\u002Fui\u002F is touched; the prompt names Tailwind, shadcn, a variant, a design token, a CSS variable, a responsive breakpoint, dark mode, or a colour; or an arbitrary bracket value like [24px] or [#1a1a1a] is about to be written. Trigger on plain requests — \"style this\", \"add a colour\", \"make this responsive\", \"match the other buttons\" — the user will not say \"Tailwind discipline\"; the class attribute is the trigger. SKIP only when no styling and no component file is touched.\n","Bash(npx shadcn@latest *), Bash(pnpm dlx shadcn@latest *), Bash(bunx --bun shadcn@latest *), Bash(npx shadcn-solid@latest *), Bash(pnpm dlx shadcn-solid@latest *), Bash(bunx --bun shadcn-solid@latest *)","main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fcode\u002Ftailwind-shadcn","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997","https:\u002F\u002Fpersonal-portfolio-v2-phi.vercel.app","Go & TypeScript developer building tooling for AI-assisted development: git worktree workflows, Claude Code skills and agent orchestration.","2026-11-11 22:26:34",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill tailwind-shadcn",{"tool":75,"command":76},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill tailwind-shadcn",{"tool":78,"command":79},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill tailwind-shadcn","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002FSKILL.md",true,[83,89,93,97,101,105,109,113],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"evals\u002Fevals.json","REFERENCE","参考文档",5166,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002Fevals\u002Fevals.json",{"path":90,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fcli-shadcn-solid.md",3907,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002Freferences\u002Fcli-shadcn-solid.md",{"path":94,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fcli.md",2663,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002Freferences\u002Fcli.md",{"path":98,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fcva.md",6515,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002Freferences\u002Fcva.md",{"path":102,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fformatting.md",1524,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002Freferences\u002Fformatting.md",{"path":106,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fprimitives-solid.md",6368,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002Freferences\u002Fprimitives-solid.md",{"path":110,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fresponsive.md",4448,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002Freferences\u002Fresponsive.md",{"path":114,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Ftheming.md",8404,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftailwind-shadcn\u002Freferences\u002Ftheming.md",[118,126,133,161,187,212],{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":125},"01M745F5J4Z2W32G4QXESCN5PM","vault-recall","Answer the user's conceptual or technical question using their Obsidian vault as well as general knowledge. Use when the user asks a question (not a task) whose topic appears in the vault MOC digest from session start. Not for task instructions, not mid-task, and not for writing to the vault (that is to-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fvault-recall\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":125},"01M745EW5W0A7K9016Z54A4KG2","ingest","Ingest one external source (an article, course lesson, doc, PDF or URL) into the user's Obsidian vault: save the original to raw\u002F, then build wiki\u002F pages per the vault's § Ingest. Use when the user types \u002Fingest, or says \"ingest this\", \"add this source to my wiki\", \"put this article\u002Flesson in the vault as a wiki page\". Works from any repo. Routing rule: someone else's words go to wiki\u002F (this skill); the user's own learnings and decisions go to notes\u002F (\u002Fto-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fingest\u002FSKILL.md",[],[],{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":54},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160],"tickets","to tickets","new","signatures","github","plan","batch","task","code","manifest","plans","true","ticket","command","repo","for","feature","run","worktrees","as","cut",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":170,"publishedAt":54},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[167],{"categoryNo":168,"categoryName":169,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[171,172,142,173,174,175,176,177,178,179,53,37,180,151,181,182,183,154,155,184,185,186,159,153],"to seams","schema","neither","it","but","file","prompt","either","use","interface","repos","block","records","build","can","record",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":196,"publishedAt":54},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[193],{"categoryNo":194,"categoryName":195,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理",[197,198,199,159,156,200,201,37,202,203,204,140,205,206,145,207,208,151,152,209,210,211],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":219,"publishedAt":54},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[218],{"categoryNo":194,"categoryName":195,"taxonomyType":29,"taxonomyTypeDesc":30},[220,221,222,223,224,225,226,227,140,228,145,229,230,231,151,210,156,232,233,159],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]