--- id: mattbx/shadcn-skills/shadcn-component-review version: "0167cbf9" license: MIT install: manual updated: 2026-04-27 --- # shadcn-component-review — This skill systematically reviews custom components and layouts to ensure they align with shadcn design patterns, visual style conventions, and modern composition practices. It catches common drift issues like hardcoded colors, inconsistent spacing, missing data-slot attributes, and anti-patterns that generation-time linting misses. Use it after writing or modifying components, or when you need to verify a layout follows shadcn idioms. Publisher: mattbx · Stars: 14 · Updated: 2026-04-27 Install (manual): `git clone https://github.com/mattbx/shadcn-skills` ## SKILL.md # 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. `