Composable Components

Quick Guide: Design component APIs the way headless primitive libraries do: a component owns behavior, state and accessibility -- the consumer owns markup and styling. Split configuration props into compound parts sharing scoped context, support controlled and uncontrolled use from the same API, let consumers substitute the rendered element (asChild or render), expose every state as a data-* attribute, and compose -- never replace -- the props, refs and handlers you receive. This is an alignment skill: run any existing component through the checklist at the end and fix what fails.

<critical_requirements>

CRITICAL: Before Using This Skill

All code must follow project conventions in CLAUDE.md (kebab-case, named exports, import ordering, import type, named constants)

(You MUST express variation as parts and children, NOT as configuration props -- a new visual requirement must be satisfiable by rearranging JSX, never by adding a boolean or a renderX prop)

(You MUST ship the full state triple for every piece of component state -- value + defaultValue + onValueChange -- and NEVER copy a controlled prop into internal state)

(You MUST compose props, event handlers and refs that arrive from the consumer, NEVER replace them -- the consumer's handler runs first and must be able to suppress your internal behavior)

(You MUST expose state as data-* attributes on every part and keep behavior parts visually unopinionated -- no default classNames, no inline colors, no baked-in transitions)