Shadcn luma

shadcn/ui — Luma style (v2, studio-wide)

The failure this skill prevents

Agents run npx shadcn@latest init or add <component> with defaults, get the default/new-york style, and call it done. Luma is a distinct shadcn style applied via a preset — it changes component GEOMETRY and SPACING, not only theme colors. A component that compiles and renders is NOT proof it's Luma-styled.

Step 0 — Verify before installing anything (always)

1. Read the project's docs/DESIGN.md — it holds project-specific overrides (e.g. consulenza360: operational density and 44–52px rows take priority over Luma airiness). The skill is the procedure; DESIGN.md is the knowledge.
2. Open components.json at repo root. Confirm the project's Luma configuration is in place (style/preset recorded there or in DESIGN.md). If it shows plain default / new-york with no Luma preset applied → Luma is NOT applied; do not add components on top. Fix per the right step below, or escalate.
3. Spot-check the global CSS: Luma ships its own CSS variable set. Stock shadcn defaults = Luma not applied.

Step 1 — New project setup (greenfield only)

Use shadcn/create or the shadcn CLI with the Vite template, Radix base, and the current Luma preset code generated by shadcn/create. The Luma preset code has been b2D0wqNxT, but ALWAYS verify the current code on shadcn/create before running:

npx shadcn@latest init --template vite --base radix --preset b2D0wqNxT   # pick Radix UI, never Base UI (studio convention)

Step 2 — Applying Luma to an existing app (orchestrator-approved only)

npx shadcn@latest apply b2D0wqNxT     # verify current preset code first

• apply re-installs existing components and updates theme, CSS variables, fonts, and icons in one pass — inspect diffs before overwriting local components; prefer applying the preset or reinstalling specific components intentionally.
• Never use shadcn apply --only theme when the task is to adopt the full Luma style — Luma changes component geometry and spacing in addition to theme tokens.
• Never approximate Luma by hand-editing CSS or Tailwind config.
• This operation touches every component: it requires an explicit orchestrator task and a visual diff of key screens before commit.

Step 3 — Adding a component (the routine case)

1. Step 0 checks pass.
2. npx shadcn@latest add <component> — the CLI reads components.json and pulls the correctly-styled variant. The recorded config IS the mechanism; that's why Step 0 matters.
3. Never modify files in src/components/ui/ — these are shadcn library files, not project code. If a primitive must change: reinstall/update via the CLI, or wrap/compose it in project code.
4. When adapting existing components manually is unavoidable: update radius, surface treatment, shadows, gaps, and control sizing to match Luma — not only theme tokens.

Step 4 — Self-verification before marking done (binary)

• Project's Luma preset/config confirmed in components.json (per Step 0)
• New component imported from @/components/ui/* (not copied from docs/web)
• Nothing in src/components/ui/ was hand-edited
• No hardcoded hex colors or stock-shadcn tokens introduced — CSS variables only
• No arbitrary Tailwind bracket values where a scale token is close (mb-14/mb-16, not mb-[60px]); no Tailwind config resurrected to "inject" theme colors (Tailwind v4 = tokens in CSS @theme)
• Project-specific DESIGN.md overrides respected (e.g. row density)
• Rendered screen visually consistent with one existing Luma page (compare)