Designing a design system

You are building a design-token system from zero, or extending an existing one with a new token family — a color system, a type scale, a spacing system, a component-sizing ladder, or the naming taxonomy that ties them together. This skill orients you across the build pipeline in the order decisions actually depend on each other, and points at the skill that carries each station's real rules; it does not re-teach them here.

When to use

• Standing up a brand-new design-token system: naming, color, type, spacing, sizing, format, versioning.
• Adding a new token family to an existing system (a new hue, a new component-sizing ladder, a new density mode).
• Deciding the build order — naming before color, color before non-color families, both before format and versioning.
• Setting or auditing the visual quality bar a system's tokens are meant to guarantee.

When NOT to use

• Reviewing rendered UI or a PR against a system's existing rules — load reviewing-design-work instead.
• Wiring a product to a system someone else owns (install, theme, upgrade) — load consuming-a-design-system instead.
• This skill is for authoring the system itself, not for consuming or auditing one.

1. Naming & taxonomy