agentsclimarketplace

Design tokens versioning

Skill almasumdev/awesome-mobile-design-system-agent-skills/.github/skills/governance/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

Install
npx -y skills add almasumdev/awesome-mobile-design-system-agent-skills --skill design-tokens-versioning

Assembled 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

ChangeBump
New token addedminor
New theme / brand addedminor
New variant on existing component tokenminor
Token value change that preserves semanticspatch
Token value change that alters semantics or contrastminor
Token rename with alias to old nameminor
Token rename without aliasmajor
Token removal (after deprecation window)major
$type change (colorshadow, etc.)major
Layer reorganization that changes public-facing token pathsmajor

"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.0
  • DSTokens Swift Package tag v3.2.0
  • ds_tokens: ^3.2.0 on 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 $deprecated in 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.Z so 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 $value from 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 $deprecated plus 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.

Keep looking

Skills are one crate of 326,629. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.