Individual skill
component-family-consistency
Buttons, inputs, badges and pills share radius, colour logic, shadow, border and spacing. Use when building, changing or reviewing UI components or a component library.
skills/component-family-consistency/SKILL.md
Source commit 8f78f13f74a2356326d0c3c21bc63e5624e6a457
What was checked
- Matches the observed repository HEAD
- Yes
- Scanner rules are current
- No
- Repository scan complete
- No
- Skill scan complete
- Yes
- Observed behavior
- Not checked yet
- Last checked
- Nov 11, 2026
These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.
Install this skill
Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.
An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.
Repository context
- Repository stars (not skill ratings)
- 192
- Repository last updated
- Nov 1, 2026
- License
- MIT
Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.
- accessibility Repository topic
- agent-skills Repository topic
- claude-code-skills Repository topic
- claude-skills Repository topic
- cursor-skills Repository topic
- design-system Repository topic
- design-tokens Repository topic
- enterprise-ux Repository topic
- skills-sh Repository topic
- typography Repository topic
- design Derived category
- design-interface Derived category
Files and excerpt
File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.
Browse files
SKILL.mdcore · 35,182 bytes
Read excerpt
# Component Family Consistency
Every interactive component in a product — buttons, inputs, selects, checkboxes, radio buttons, pills, badges, tags, calendars, date pickers, sliders, toggles — belongs to the same visual family. They share a common design DNA. A user should be able to look at any component and feel that it belongs to the same product as every other component.
When components are designed in isolation without shared tokens, the product feels assembled from parts rather than built as a whole.
## Reuse Before You Build a New Component
The rule, stated as directives:
> Use existing components from the component library. Build a new one only after the audit below finds nothing that fits.
> Do not invent a new visual presentation if a fitting component exists.
> With every UI code change, check the changed files and their nearest sibling components for matching use cases, and keep them coherent. Report drift found elsewhere instead of fixing it unasked.
> The goal is a UI that strictly follows the design system, with no ad-hoc components.