Shadcn Code Review

Reviews shadcn/ui components for CVA patterns, composition with asChild, accessibility states, and data-slot usage. Use when reviewing React components using...

Security Scan

The skill is a coherent, instruction‑only code‑review helper for shadcn/ui patterns, but it references a required 'review‑verification‑protocol' checklist that is not included — making its hard gating impossible to satisfy and creating an operational/integrity gap you should resolve before trusting results.

Purpose & Capability

Name/description match the contents: an instruction-only code review for shadcn/ui patterns. The provided reference docs (cva, composition, accessibility, data-slot) align with the stated purpose and there are no unrelated binaries, env vars, or installs requested.

Instruction Scope

The SKILL.md appropriately instructs the agent to read repository files and produce location-backed findings (expected for a code-review skill), but it requires completing a Pre-Report Verification Checklist located at ../review-verification-protocol/SKILL.md — that file is not present in the manifest, so the agent cannot complete Hard Gate 4 as written. This is an operational inconsistency (the gating step is unfulfillable).

Install Mechanism

No install steps, no downloads, and no code files — lowest-risk instruction-only skill. The regex scanner had no files to analyze beyond the included Markdown references.

Credentials

The skill requests no environment variables, credentials, or config paths. All required inputs are repository file contents, which is proportionate to a code-review task.

Persistence & Privilege

Flags are default (always:false, model invocation allowed). The skill does not request permanent presence or system-wide config changes.

What to consider before installing

This skill appears to be a legitimate, instruction-only code-review checklist for shadcn/ui patterns and does not request secrets or install code. However, SKILL.md requires completing a 'review-verification-protocol' checklist (Hard Gate 4) referenced at ../review-verification-protocol/SKILL.md but that file is not included in the skill bundle — meaning the agent cannot follow the stated gating process as-is. Before installing or running this skill: 1) ask the skill author to include the missing review-verification-protocol file (or embed the checklist into SKILL.md) so the hard gates are actually enforceable; 2) confirm the agent will only be given access to the repository you want reviewed (the skill expects to read code files and produce verbatim quotes and paths); 3) if you plan to allow autonomous invocation, be aware the skill will read repository content to generate findings — limit its scope to intended repos; 4) if you need stronger assurance, request the author add an explicit statement about whether the skill will call external services or upload excerpts (none are referenced currently). Resolving the missing-checklist gap will move this from 'suspicious' toward 'benign'.

shadcn/ui Code Review

Quick Reference

Issue Type	Reference
className in CVA, missing VariantProps, compound variants	references/cva-patterns.md
asChild without Slot, missing Context, component composition	references/composition.md
Missing focus-visible, aria-invalid, disabled states	references/accessibility.md
Missing data-slot, incorrect CSS targeting	references/data-slot.md

Review Checklist

• cn() receives className, not CVA variants
• VariantProps<typeof variants> exported for consumers
• Compound variants used for complex state combinations
• asChild pattern uses @radix-ui/react-slot
• Context used for component composition (Card, Accordion, etc.)
• focus-visible: states, not just :focus
• aria-invalid, aria-disabled for form states
• disabled: variants for all interactive elements
• sr-only for screen reader text
• data-slot attributes for targetable composition parts
• CSS uses has() selectors for state-based styling
• No direct className overrides of variant styles

Hard gates (before writing findings)

Run these in order. Do not draft user-facing findings until every gate passes for the batch you are about to report.

1. Location evidence — Pass: Each issue lists a repo path and either a line range or a short verbatim quote from the file you read (not from memory or diff-only guesswork).

2. Exemption check — Pass: For each issue, you can state in one line why it is not covered by Valid Patterns (Do NOT Flag).

3. Context-sensitive claims — Pass: For accessibility or Radix-related flags, you checked the file for imports/wrappers showing what actually runs (or you cite the concrete gap).

4. Protocol — Pass: You completed the Pre-Report Verification Checklist in review-verification-protocol for this review.

Valid Patterns (Do NOT Flag)

These are correct patterns that should NOT be flagged as issues:

• max-h-(--var) - correct Tailwind v4 CSS variable syntax (NOT v3 bracket notation)
• text-[color:var(--x)] - valid arbitrary value syntax
• Copying shadcn component code into project - intended usage pattern
• Not documenting copied shadcn components - library internals, not custom code
• Using cn() with many arguments - composition is the pattern
• Conditional classes in cn() arrays - valid Tailwind pattern
• Extending primitive components without additional docs - well-known base

Context-Sensitive Rules

Apply these rules with appropriate context awareness:

• Flag accessibility issues ONLY IF not handled by Radix primitives underneath
• Flag missing aria labels ONLY IF component isn't using accessible radix primitive
• Flag variant proliferation ONLY IF variants could be composed from existing
• Flag component documentation ONLY IF it's custom code, not copied shadcn

Library Convention Note

shadcn/ui components are designed to be copied and modified. Code review should focus on:

• Custom modifications made to copied components
• Integration with application state/data
• Accessibility in custom usage contexts

Do NOT flag:

• Standard shadcn component internals
• Radix primitive usage patterns
• Default variant implementations

When to Load References

• Reviewing variant definitions → cva-patterns.md
• Reviewing component composition with asChild → composition.md
• Reviewing form components or interactive elements → accessibility.md
• Reviewing multi-part components (Card, Select, etc.) → data-slot.md

Review Questions

1. Are CVA variants properly separated from className props?
2. Does asChild composition work correctly with Slot?
3. Are all accessibility states (focus, invalid, disabled) handled?
4. Are data-slot attributes used for component part targeting?
5. Can consumers extend variants without breaking composition?

Before Submitting Findings

Complete Hard gates (especially gate 4), then report only issues that still pass the review-verification-protocol pre-report checks.