ui-designer/component-specification

Create a state matrix for each component covering default, hover, pressed, focus, disabled, loading, and error states with concrete token values. This Skill provides ready-made tables for buttons, inputs, and form controls that map each state to colors, borders, and cursor behavior.

A button spec should define variants (primary, secondary, ghost, danger, link), sizes with exact height and padding values, and all interaction states. It should also cover icon buttons, loading spinners, and provide TSX code examples for each variant.

Yes, it depends on a design system skill that supplies tokens like Primary, Gray-300, radius-md, and shadow-lg. The component specs reference these tokens rather than hardcoding raw values, keeping components consistent with the broader design language.

Inconsistency usually comes from missing specifications: designers only document default states, sizes are not aligned across components, and edge cases like long text or empty states are ignored. A complete spec with state tables and sizing rules prevents these gaps.

Markdown specs document intent but cannot enforce it in code or render live previews. Teams needing interactive documentation should pair the spec with a component library or Storybook, using the Markdown tables as the source of truth for values.