component-family-consistency

Name: component-family-consistency
Author: dembrandt

27stars5forks

How to install component-family-consistency?

dembrandt/dembrandt-skills/component-family-consistency

$npx -y skills add dembrandt/dembrandt-skills --skill component-family-consistency

Installs into the current project.

Summary

Buttons, inputs, pills, badges, calendars, and other interactive components form a visual family — they share the same border-radius, colour logic, shadow scale, border style, and spacing rhythm. Inconsistency between them breaks the sense of a coherent product. Use when building

Files · 1

View on GitHub

SKILL.md

1	# Component Family Consistency
2
3	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.
4
5	When components are designed in isolation without shared tokens, the product feels assembled from parts rather than built as a whole.
6
7	## Reuse Before You Build a New Component
8
9	Before creating any component, audit what already exists — a new-from-scratch component is another mouth to feed: another entry in the family that must stay consistent (radius, height, states, motion) and another thing to maintain. Building fresh should be the last resort, not the first move. Work down this order:
10
11	1. Is there already a component that does this? Use it as-is. If it almost fits, extend it with a prop or variant rather than cloning it — one flexible `Button` beats `PrimaryButton`, `BigButton`, and `CtaButton` living in parallel.
12	2. Is there something close in the codebase you can generalise? Often a one-off was built inline for a single screen. If a small change would make it generic — lift it into the shared library, parameterise the hard-coded bits (label, colour, size via props/tokens), drop the screen-specific assumptions — do that instead of writing a second near-identical thing.
13	3. Only build new when nothing existing fits and nothing can be reasonably generalised — and when you do, build it from the shared DNA below so it joins the family cleanly.
14
15	Parallel one-offs — three near-identical buttons, two cards with different radius — are how a design system drifts. Before adding a component, ask: does this exist, or is it one refactor from existing?
16
17	The inverse also holds: a visual treatment that appears independently in 2–3 places has earned promotion — name it and make it a shared component or token before a fourth copy appears. And when pages from different design eras disagree, migrate old toward new: the newest components are the best evidence of current intent, but confirm before deprecating a style — see [`generate-ui-from-brand`](../generate-ui-from-brand/SKILL.md) for the consolidation pass.
18
19	> Find the inconsistency automatically (dembrandt engine, optional). Spotting where a live product has already diverged — five near-identical button radii, three greys that should be one — is tedious by eye. `get_findings` runs a design-system lint over a real extraction and reports consistency and duplication issues to consolidate. (And `compute_drift` scores how far two extractions have drifted apart — e.g. this product vs. its reference, or before vs. after a cleanup.) Use them to audit an existing product before deciding what to reuse. See [`extract-design`](../extract-design/SKILL.md).
20
21	## The Shared DNA
22
23	Define these tokens once. Every component inherits from them.
24
25	### Border-Radius
26	All interactive components use the same base radius token. Variations are derived, not invented.
27
28	```css
29	--radius-base: 8px; /* buttons, inputs, selects */
30	--radius-sm: 4px; /* checkboxes, small badges */
31	--radius-lg: 12px; /* cards, modals, large panels */
32	--radius-full: 9999px; /* pills, tags, avatar chips */
33	```
34
35	A button and an input on the same form must have the same radius. A pill is always `--radius-full`. A badge is `--radius-sm` or `--radius-ful

People who liked this also viewed

6 picks

Type

component-family-consistency

27stars5forks

View on GitHub

How to install component-family-consistency?

dembrandt/dembrandt-skills/component-family-consistency

$npx -y skills add dembrandt/dembrandt-skills --skill component-family-consistency

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Component Family Consistency
2
3	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.
4
5	When components are designed in isolation without shared tokens, the product feels assembled from parts rather than built as a whole.
6
7	## Reuse Before You Build a New Component
8
9	Before creating any component, audit what already exists — a new-from-scratch component is another mouth to feed: another entry in the family that must stay consistent (radius, height, states, motion) and another thing to maintain. Building fresh should be the last resort, not the first move. Work down this order:
10
11	1. Is there already a component that does this? Use it as-is. If it almost fits, extend it with a prop or variant rather than cloning it — one flexible `Button` beats `PrimaryButton`, `BigButton`, and `CtaButton` living in parallel.
12	2. Is there something close in the codebase you can generalise? Often a one-off was built inline for a single screen. If a small change would make it generic — lift it into the shared library, parameterise the hard-coded bits (label, colour, size via props/tokens), drop the screen-specific assumptions — do that instead of writing a second near-identical thing.
13	3. Only build new when nothing existing fits and nothing can be reasonably generalised — and when you do, build it from the shared DNA below so it joins the family cleanly.
14
15	Parallel one-offs — three near-identical buttons, two cards with different radius — are how a design system drifts. Before adding a component, ask: does this exist, or is it one refactor from existing?
16
17	The inverse also holds: a visual treatment that appears independently in 2–3 places has earned promotion — name it and make it a shared component or token before a fourth copy appears. And when pages from different design eras disagree, migrate old toward new: the newest components are the best evidence of current intent, but confirm before deprecating a style — see [`generate-ui-from-brand`](../generate-ui-from-brand/SKILL.md) for the consolidation pass.
18
19	> Find the inconsistency automatically (dembrandt engine, optional). Spotting where a live product has already diverged — five near-identical button radii, three greys that should be one — is tedious by eye. `get_findings` runs a design-system lint over a real extraction and reports consistency and duplication issues to consolidate. (And `compute_drift` scores how far two extractions have drifted apart — e.g. this product vs. its reference, or before vs. after a cleanup.) Use them to audit an existing product before deciding what to reuse. See [`extract-design`](../extract-design/SKILL.md).
20
21	## The Shared DNA
22
23	Define these tokens once. Every component inherits from them.
24
25	### Border-Radius
26	All interactive components use the same base radius token. Variations are derived, not invented.
27
28	```css
29	--radius-base: 8px; /* buttons, inputs, selects */
30	--radius-sm: 4px; /* checkboxes, small badges */
31	--radius-lg: 12px; /* cards, modals, large panels */
32	--radius-full: 9999px; /* pills, tags, avatar chips */
33	```
34
35	A button and an input on the same form must have the same radius. A pill is always `--radius-full`. A badge is `--radius-sm` or `--radius-ful

People who liked this also viewed

6 picks

Type