Skill / UI / Tailwind
ClassName boundaries
Use component APIs for intended variation instead of overriding design-system internals with className.
Goal
Keep component contracts meaningful and avoid style drift from consumer overrides.
Styling rules for Tailwind v4, token discipline, component reuse, and className boundaries.
Checks
1Compose className values with `cn()`, never template literals.
2On the docs website, keep shared-component className values to caller-owned layout and placement such as width constraints, flex or grid alignment, positioning, overflow, and responsive visibility.
3Choose props, variants, sizes, tones, colors, slots, and composition for component-owned presentation.
4If the required treatment is missing, add a meaningful component variant instead of styling one consumer into a new variant.
5Use Tailwind v4 trailing important syntax when needed: `fixed!`, `bottom-0!`, `translate-x-0!`.
Avoid
1Passing long className strings into shared components to bypass their variants.
2Overriding control height, padding, radius, color, border, background, typography, shadow, focus treatment, or motion from a docs-site consumer.
3Using older leading important utilities such as `!fixed` in Tailwind v4 code.
Source
Imported as local Control UI skill guidance, with this repo owning the final wording.
Mastra tailwind-v4
../mastra/.claude/skills/tailwind-v4