--- name: shadcn-component-review description: Review custom components and layouts against shadcn design patterns, visual style conventions (Vega, Nova, Maia, Lyra, Mira), composition rules, design token usage, and Radix/Base UI composition patterns. Use PROACTIVELY after writing or modifying any custom UI component, page layout, or variant of a shadcn component. Use when the user says "review this component", "check my spacing", "does this follow shadcn patterns", "audit this layout", "is this shadcn-idiomatic", or shares a component for feedback. Catches spacing drift, hardcoded colors, missing data-slot attributes, inconsistent theme application, and composition anti-patterns that shipping-fast-with-AI tools often miss. --- # shadcn Component Review Systematic audit process for ensuring custom components align with shadcn design patterns, the project's chosen visual style, and modern composition conventions. ## How This Complements the Official shadcn Skill The official `shadcn` skill (shipped with CLI v4) enforces rules at *generation time* — telling agents "use `gap-*` not `space-y-*`, use semantic colors, use `size-*` for equal width/height," and so on. That's correct behavior when writing new code. This skill is for *post-hoc audit* — reviewing components that already exist (written by Claude, by a teammate, by a previous iteration) against those same rules *plus* the visual-style-specific patterns that vary by theme (Vega spacing differs from Maia differs from Mira). When the two skills both apply, the official handles forward-generation and this one handles retrospective review. They don't conflict — they check the same rules from different directions. ## Core Principle Reviews catch drift. Even with the official skill enforcing rules during generation, components drift over time: someone copies from an older project, an LLM suggests `space-y-4` and nobody catches it, a component was built before the project standardized on Maia, or a contributor uses Tailwind's color scale instead of semantic tokens. This skill finds those issues systematically. ## When to Trigger **Proactive triggers** (activate after components are written): - Claude just finished writing or modifying a custom component - User says "I built this" and pastes a component - User asks to add styling to an existing element - User is iterating on a layout **Explicit triggers** (user directly requests review): - "Review this component" - "Check my spacing" - "Is this shadcn-idiomatic?" - "Does this follow the patterns?" - "Audit this layout" ## Before Reviewing: Project Context Before applying theme-specific patterns, understand the project. If the shadcn CLI is available, run: ```bash npx shadcn@latest info --json ``` This returns: framework (Next.js / Vite / etc.), Tailwind version, base library (`radix` or `base`), installed components, icon library, resolved file paths, and the current style. Use this output to: - Match spacing/shape expectations to the project's visual style - Apply the correct composition pattern for the primitive base (Radix vs Base UI — APIs differ) - Know which components are already installed vs suggesting installs If the CLI isn't available, infer from `components.json` directly, or ask the user: "Which visual style is this project using — Vega, Nova, Maia, Lyra, or Mira?" ## Review Workflow ### Step 1: Structure & Composition Check the component is structured using shadcn conventions. **`data-slot` attributes.** Every semantic element within a component should carry a `data-slot` attribute naming its role. This enables styling hooks, testing selectors, and consistent theming. Confirmed current pattern in shadcn source (e.g. `