design-system-governance
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).
- Installs
- 1.7K
- Last 24h
- +23
- Trending rank
- #5188
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/owl-listener/designer-skills --skill design-system-governance- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads design-system-governance automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
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:
- Who owns the system? Dedicated team, federated contributors, or hybrid?
- Who can contribute? Anyone, or only the core team?
- How are changes proposed and decided? Request process, RFC, or open pull requests?
- How is the system versioned? How do consumers know what changed?
- How are breaking changes handled? How much notice, what migration support?
- What gets deprecated, and how? Timeline and removal process?
- 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:
- Request/Proposal: product team identifies a need; submits a request with use case and context
- Triage: core team assesses: is this generalizable? Does something similar exist? What's the priority?
- Design: component designed and specced (states, variants, accessibility, tokens)
- Review: design critique + accessibility review + engineering feasibility
- Build and test: implementation, documentation, accessibility testing
- Release: versioned release with changelog entry
- Communication: announce to consumers with migration notes if applicable
Versioning
Use semantic versioning (semver) as the communication contract:
| Version type | When to use |
|---|---|
| Patch (1.0.x) | Bug fixes, documentation corrections, no API changes |
| Minor (1.x.0) | New components or variants added; backwards compatible |
| Major (x.0.0) | Breaking changes: renamed props, removed components, changed behavior |
- Tag every release in version control
- Maintain a public changelog — consumers need to know what changed and why
- Keep major version bumps rare and well-communicated
Deprecation Process
- Announce deprecation with the release that introduces the replacement
- Provide a migration guide: what replaces the deprecated item, with code examples
- Keep deprecated items functional for at least one minor version cycle before removal
- Use in-product warnings (console warnings, Figma annotations) to surface deprecations to consumers
- Communicate timelines clearly: "Deprecated in 2.3, removed in 3.0 (Q3)"
Breaking Change Policy
Before releasing a breaking change:
- Give consumers a migration path (a codemod, a replacement component, a spec change)
- Document the change in the changelog with "BREAKING:" prefix
- Provide a migration guide in docs
- Consider a compatibility shim for critical consumers who can't migrate immediately
Quality Standards
Define what a component must have before it can enter the system:
- Documented props, variants, and states
- Accessibility review (WCAG AA minimum, keyboard navigation, screen reader tested)
- Responsive behavior specified
- Design token usage (no hardcoded values)
- Usage guidance (when to use, when not to use)
- Design file component (Figma or equivalent) synced with code
Best Practices
- Publish a clear contribution guide so product teams know how to participate
- Hold regular office hours or open reviews — governance works better as a conversation than a ticket queue
- Review adoption metrics (which components are used most/least) to guide investment
- Document decisions as well as outcomes — why a component works the way it does prevents revisiting settled debates
- Treat governance as a product: it has users (contributors and consumers), and it needs iteration
FAQ
What does the design-system-governance skill do?
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).
How do I install design-system-governance?
Run npx skills add https://github.com/owl-listener/designer-skills --skill design-system-governance in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/design-system-governance/ (personal) or .claude/skills/design-system-governance/ (project).
Which AI agents can use design-system-governance?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is design-system-governance safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains design-system-governance?
It is published by owl-listener in owl-listener/designer-skills. It has 1,738 recorded installs.
More from owl-listener/designer-skills
presentation-deck
owl-listener/designer-skills
Structure a design presentation for a specific audience and decision. Use when presenting internally. For a portfolio narrative use case-study; for the written argument use design-rationale.
typography-scale
owl-listener/designer-skills
Create a modular type scale with size, weight, and line-height relationships. Use when establishing typographic structure. For line length only use readable-measure; for judging type on an existing screen use critique-typography (visual-critique).
illustration-style
owl-listener/designer-skills
Define an illustration style guide — visual language, colour usage, and application rules. Use when commissioning or standardising illustration. For icons, use icon-system (design-systems).
visual-hierarchy
owl-listener/designer-skills
Establish hierarchy through size, weight, colour, spacing, and position so the eye lands in the intended order. Use when composing new work. For judging an existing screen, use critique-visual-hierarchy (visual-critique).
color-system
owl-listener/designer-skills
Build a product colour system — tonal scales, semantic roles, and contrast compliance. Use when defining or rebuilding colour from scratch. For dark-mode adaptation use dark-mode-design; for chart palettes use data-visualization; for multi-brand token architecture use theming-system (design-systems).
dark-mode-design
owl-listener/designer-skills
Adapt an existing palette to dark mode — surface elevation, contrast rebalancing, and desaturation rules. Use when you already have a light palette to translate. For building the base palette first, use color-system.
Popular frontend & design skills
setup-matt-pocock-skills
mattpocock/skills
Configure this repo for the engineering skills: set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.
frontend-design
anthropics/skills
Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.
hyperframes-animation
heygen-com/hyperframes
All animation knowledge for HyperFrames — atomic motion rules, multi-phase scene blueprints, scene transitions, broader motion-design techniques, AND the seven runtime adapters (GSAP default, plus Lottie, Three.js, Anime.js, CSS keyframes, Web Animations API, TypeGPU). Use for any motion or animation task: pick 2-4 rules and compose, or load a blueprint, or look up runtime-specific API (e.g. GSAP eases / Lottie player / Three.js mixer). Also covers auditing an existing composition's choreography (animation map) and 24 named text-animation effects. HyperFrames-native: single paused timeline, seek-safe, deterministic.
prototype
mattpocock/skills
Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
hyperframes-core
heygen-com/hyperframes
The HyperFrames composition contract — build one renderable project. Use for composition structure, the data- timing attributes, class="clip", tracks, sub-compositions, variables, framework-owned media playback, deterministic-render rules, and validation. Read before writing composition HTML.
vercel-react-best-practices
vercel-labs/agent-skills
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.