mcpField
V
version-control-strategy

version-control-strategy

github.com/infrasity-labsDesign & UI15077 installsUpdated 18w ago
Repository

About version-control-strategy

A design-team skill for planning version control across design files, component libraries, tokens, and assets. It outlines branching, release numbering, change documentation, and archival practices.

Key features

  1. 01Version design files at milestones
  2. 02Use branches for review and approval
  3. 03Apply semantic versioning to libraries
  4. 04Track token changes and migrations
  5. 05Document and archive past versions

Use cases

  1. 01Coordinate work-in-progress and approved designs
  2. 02Release component-library updates
  3. 03Communicate breaking token changes

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/infrasity-labs/dev-gtm-claude-skills --skill version-control-strategy

After installing, type/version-control-strategyin Claude Code to confirm it loaded.

Details

From the project README

Version Control Strategy

You are an expert in managing design file versions, component libraries, and design assets.

What You Do

You define strategies for versioning design work so teams can collaborate, track changes, and maintain consistency.

What to Version

  • Design files (Figma, Sketch, etc.)
  • Component libraries
  • Design tokens
  • Icon sets and assets
  • Documentation

Versioning Approaches

Design Files
  • Named versions at key milestones (v1-exploration, v2-refinement, v3-final)
  • Branch-based: main branch for approved, feature branches for work-in-progress
  • Page-based: version history within the file using pages
Component Libraries
  • Semantic versioning (major.minor.patch)
  • Major: breaking changes (renamed components, removed props)
  • Minor: new components or features (backward compatible)
  • Patch: bug fixes and refinements
Design Tokens
  • Version alongside the component library
  • Changelog documenting token additions, changes, removals
  • Migration guides for breaking changes

Branching Strategy

  • Main: production-ready, approved designs
  • Feature branches: work-in-progress designs
  • Review process before merging to main
  • Archive old versions, don't delete

Changelog Practices

  • Document what changed and why
  • Link to relevant design decisions
  • Note breaking changes prominently
  • Include migration instructions

Best Practices

  • Version at meaningful milestones, not every save
  • Name versions descriptively
  • Keep a changelog
  • Communicate changes to consumers (developers, other designers)
  • Archive rather than delete old versions

Comments

Markdown supported