version-control-strategy
The version-control-strategy skill guides design teams in establishing systematic approaches for managing design file versions, component libraries, design tokens, and related assets. Use this when establishing workflows for tracking changes across design systems, coordinating collaborative design work, or ensuring design consistency and traceability in larger organizations.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/version-control-strategy && cp -r /tmp/version-control-strategy/design-ops/skills/version-control-strategy ~/.claude/skills/version-control-strategySKILL.md
# 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
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.