# Design System Governance

Define how the system evolves, contribution model, versioning, deprecation, and change...

- Repository: https://github.com/Owl-Listener/designer-skills (3196 stars)
- Category: Design
- License: MIT
- Last updated: 2026-09-05
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add Owl-Listener/designer-skills --skill design-system-governance -g -a claude-code -y`
Codex: `npx skills add Owl-Listener/designer-skills --skill design-system-governance -g -a codex -y`
Cursor: `npx skills add Owl-Listener/designer-skills --skill design-system-governance -g -a cursor -y`
Gemini CLI: `npx skills add Owl-Listener/designer-skills --skill design-system-governance -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add Owl-Listener/designer-skills`

## Description

Define how the system evolves, contribution model, versioning, deprecation, and change management. Use when multiple teams contribute. For driving uptake use `design-system-adoption` (designer-toolkit); for design file history use `version-control-strategy` (design-ops).

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Design System Governance
You are an expert in the operational and organizational structures that keep a design system healthy over time.
## What You Do
You define the processes, roles, and decision frameworks that allow a design system to evolve without fragmenting, so contributors know how to participate, consumers know how to depend on it, and the system stays coherent as the product scales.
## Core Governance Questions
A governance model must answer:
1. **Who owns the system?** Dedicated team, federated contributors, or hybrid?
2. **Who can contribute?** Anyone, or only the core team?
3. **How are changes proposed and decided?** Request process, RFC, or open pull requests?
4. **How is the system versioned?** How do consumers know what changed?
5. **How are breaking changes handled?** How much notice, what migration support?
6. **What gets deprecated, and how?** Timeline and removal process?
7. **How is quality maintained?** Review process before merging new components?
## Ownership Models
### Centralized (Core Team)
A dedicated design system team owns all components. Consumers submit requests; the core team builds and maintains.
- High consistency, high quality
- Can become a bottleneck; slow to respond to product team needs
- Works best in large orgs with budget for a dedicated team
### Federated (Distributed)
Any product team can contribute components. A lightweight governance layer reviews and accepts contributions.
- Fast to grow; reflects actual product needs
- Requires strong review standards to maintain quality
- Works best in mid-size orgs with mature design practice
### Hybrid
Core team owns foundational components; product teams own domain-specific components with support from core.
- Balances quality with velocity
- Requires clear ownership boundaries ("core" vs "extended" library)
- Most common model in practice
## Contribution Process
Define the lifecycle of a new component or change:
1. **Request/Proposal**: product team identifies a need; submit

The rest: https://github.com/Owl-Listener/designer-skills/blob/HEAD/design-systems/skills/design-system-governance/SKILL.md