Design tokens versioning
Semantic versioning for design tokens — deprecation, breaking changes, and migration. Use this when releasing token changes or planning a major bump.From its SKILL.md
npx -y skills add almasumdev/awesome-mobile-design-system-agent-skills --skill design-tokens-versioningAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.5 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
Design Tokens Versioning
Instructions
Tokens are a public API. Treat them with the same SemVer discipline as any library: additive changes are minor, breaking changes are major, and every breaking change ships with a migration path.
1. SemVer for Tokens
| Change | Bump |
|---|---|
| New token added | minor |
| New theme / brand added | minor |
| New variant on existing component token | minor |
| Token value change that preserves semantics | patch |
| Token value change that alters semantics or contrast | minor |
| Token rename with alias to old name | minor |
| Token rename without alias | major |
| Token removal (after deprecation window) | major |
$type change (color → shadow, etc.) | major |
| Layer reorganization that changes public-facing token paths | major |
"Preserve semantics": the same element continues to look the same to a user (e.g., a hex value nudged for contrast compliance within the same role).
2. Deprecation Protocol
Every removal ships through deprecation.
Step 1 — Annotate:
{
"color": {
"brand": {
"50": {
"$value": "{color.brand.100}",
"$deprecated": true,
"$description": "Deprecated since v3.2.0. Use color.brand.100.",
"$extensions": {
"com.designsystem.deprecation": {
"replacement": "color.brand.100",
"removeInVersion": "4.0.0"
}
}
}
}
}
}
Step 2 — Warn on use: emit platform-native warnings in generated output.
@Deprecated("Use DsTokens.Color.Brand100", ReplaceWith("DsTokens.Color.Brand100"))
val Brand50 = Color(0xFF...)
@available(*, deprecated, renamed: "DSTokens.Color.brand100")
public static let brand50 = UIColor(...)
@Deprecated('Use DsTokens.color.brand100')
static const brand50 = Color(0xFF...);
Step 3 — Ship one full minor cycle before removal. For high-traffic tokens, two minors.
Step 4 — Codemod: publish a codemod (ESLint rule, ktlint rule, dart-fix script, or shell sed) that rewrites consumer code.
3. Aliases as Soft Rename
When renaming, keep the old path as an alias for one version:
{
"color": {
"action": {
"primary": {
"bg": { "$value": "{color.brand.40}" },
"default": { "$value": "{color.action.primary.bg}", "$deprecated": true }
}
}
}
}
4. Breaking Change Checklist
Before merging a major bump:
- All removed tokens spent ≥ 1 minor cycle with
$deprecated. - Replacement exists for every removed token.
- Codemod published and tested on the flagship consumer app.
- Migration guide published at
docs/migrations/vN.md. - CHANGELOG entry calls out every breaking change with before/after examples.
- Visual regression run against flagship app using the new major; diffs reviewed and approved.
5. Versioning Generated Artifacts
Token packages follow the repo version:
com.ds:ds-tokens:3.2.0DSTokensSwift Package tagv3.2.0ds_tokens: ^3.2.0on pub.dev@ds/[email protected]on npm
Do not publish one platform at a different version than the others. The same repo tag produces all four artifacts atomically.
6. Release Notes
Group notes by audience and layer. A consumer developer cares about different things than a DS contributor.
## 3.3.0 — 2026-05-14
### Added
- `color.feedback.info.*` tokens.
- Component: `Callout`.
### Deprecated
- `color.brand.50` (use `color.brand.100`). Removed in 4.0.
### Fixed
- Contrast of `color.content.muted` on `color.surface.subtle` in dark theme (was 3.8:1, now 4.6:1).
7. Tooling
- changesets (
@changesets/cli): per-PR markdown fragments are aggregated at release; emits SemVer bump and changelog. - token-lint / spectral: custom rules for "a removed token must have
$deprecatedin the previous minor." - ts-migrate / jscodeshift / openrewrite / dart-fix: run codemods platform by platform.
8. Consumer-Side Policy
Document what consumers should expect:
- Pin to
^X.Y.Zso minor and patch updates flow; majors are opt-in. - Major upgrades come with a published migration guide and codemod.
- Renovate / Dependabot PRs for patch/minor auto-merge after CI passes.
9. Anti-Patterns
- Shipping a token rename as a patch because "it's just a rename."
- Removing a token in the same version it was deprecated.
- Changing a
$valuefrom light blue to red and calling it patch. - Multiple token package versions across platforms (Android on 3.2, iOS still on 2.9).
- No codemod for breaking changes — forces manual rewrites across every consumer.
Checklist
- A documented SemVer policy classifies every change type as major / minor / patch.
- Every removal has ≥ 1 minor cycle of
$deprecatedplus a replacement. - Platform artifacts emit native deprecation warnings.
- Codemods ship with every breaking change.
- All platforms publish at the same version from the same repo tag.
- Release notes are generated from PR fragments and call out breaking changes with before/after.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most design frontend skills give in ~1.3k tokens
Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07
- Use CSS variables for color consistencyin 72 of 1169, across 23 files
- Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
- Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
- Add atmospheric background effects and texturesin 57 of 1169, across 9 files
- Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
- Implement real working codein 55 of 1169, across 7 files
- Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
- Launch chromium in headless modein 47 of 1169, across 4 files
- Close the browser when donein 47 of 1169, across 4 files
- Run provided scripts with help flag firstin 47 of 1169, across 4 files
- Wait for network idle statein 47 of 1169, across 4 files
- Use descriptive selectors for elementsin 47 of 1169, across 4 files
Said here and by no other author read
- apply semantic versioning to all token changes
- annotate removed tokens with $deprecated metadata
- emit native deprecation warnings in generated output
- keep deprecated aliases for one full version cycle
- publish a codemod for every breaking change
- publish a migration guide for every major bump
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.