ui-styling

Define the variant's semantic purpose and its default, hover, focus-visible, active, disabled, and error states, reusing shared state styles. Extend shared component variants only when the behavior is shared by multiple consumers; keep one-feature layouts local.

Derive dimensions from shared control tokens such as --button-*, --input-control-*, and --dropdown-control-* in the consuming scope. Use semantic classes like bg-background and text-muted-foreground rather than arbitrary fixed pixel values.

Use it for unresolved styling or interaction implementation questions, new controls, and layout or appearance changes. Routine copy edits and pure logic changes do not need this skill.

Yes. Changed tokens must respond to supported themes, global colors, density, and radius settings. Verification includes checking affected states in each applicable theme rather than assuming one theme proves another.

Generic reference examples are topic guidance, not the project's component API. The installed declarations and existing Shell implementations are the authority; copying examples risks creating a parallel UI or theme system.

Reuse Shell primitives built on accessible foundations, preserve visible focus-visible indicators, and keep overlays in the owning Shell Portal container. The bundled accessibility reference covers focus traps, ARIA labels, and keyboard patterns.