design-token-pipelinelisted

# design-token-pipeline Tokens are the contract between design tools and shipped code. This skill covers the format, the layer model, the build, and the governance rules the format does not prescribe. ## Format: DTCG 2025.10 Stable spec from the W3C Design Tokens Community Group (October 2025). Prefer it for new files. | Property | Role | |---|---| | `$value` | The value (reserved word) | | `$type` | Kind: `color`, `dimension`, `fontFamily`, `fontWeight`, `duration`, `cubicBezier`, `number`, `string`, `boolean`, `strokeStyle`, `border`, `transition`, `shadow`, `gradient`, `typography`, `fontStyle` | | `$description` | Human doc that travels with the token | | `$extensions` | Vendor/team metadata, namespaced keys | - Spec keys use `$`. Token and group names must not start with `$`. - A token is an object with `$value`. Without it, the object is a group. - Groups may set `$type` (inherited), `$description`, `$deprecated`, `$extends`, `$root`. - Aliases: `{color.brand.blue}` curly-brace path references. - Colors in 2025.10 are objects with a colour space plus components (`srgb`, `hsl`, `hwb`, `lab`, `lch`, `oklab`, `oklch`), not bare hex. Keep an optional hex only as a fallback for old tools. - Do not put `{` `}` `.` in token/group names (alias and path rules). Style Dictionary v4 reads DTCG natively. Full 2025.10 colour-object support is still landing in v5; check the version you pin before migrating hex-only colour tokens. ## Layer model (the spec does not mandate one)