New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Design System Governance

by Owl-Listener in Owl-Listener/designer-skills

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

MITAuto-check passedFrontend & Design

Install Design System Governance

skills CLI
$ npx skills add Owl-Listener/designer-skills --skill design-system-governance -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Owl-Listener/designer-skills design-system-governance --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Owl-Listener/designer-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/design-systems/skills/design-system-governance .claude/skills/design-system-governance && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
design-system-governance
GitHub stars
2.9k
Used in
1 other repo
Token cost
~1.3k tokens
SKILL.md length
657 words
Files
1
Skills in repo
107
Repo updated
First seen
Licence
MIT

At a glance

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

  • Works in 7 steps: Who owns the system? Dedicated team,… → Who can contribute? Anyone, or only the… → How are changes proposed and decided?… → …
  • Multiple teams contribute
  • SKILL.md covers What You Do, Core Governance Questions, Ownership Models and Contribution Process, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Design System Governance is an agent skill from Owl-Listener/designer-skills. 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).

Its SKILL.md is about 1.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Frontend & Design, covering Design systems and Git workflow. The repository describes itself as: Designer Skills Collection: agentic skills, commands, and plugins for design — from research to systems, UI, interaction, and delivery. The licence is MIT.

When your agent uses it

  • Multiple teams contribute
  • Tasks that involve Design systems
  • Tasks that involve Git workflow

Example prompts

  • “/design-system-governance”

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  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?

What it can do on your machine

Read from SKILL.md and the folder at commit 9a6930c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Design System Governance loads about 1.3k tokens when it runs. Until then it costs about 74 tokens; SKILL.md has 657 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~74
When it runs · the whole SKILL.md, loaded when a task matches
~1.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Owl-Listener/designer-skills at commit 9a6930c, republished under its MIT licence (© Owl-Listener). 657 words, ~1,266 tokens.

Download SKILL.mdSave it as .claude/skills/design-system-governance/SKILL.md (or your agent's skills folder).
name
design-system-governance
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).

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; submits a request with use case and context
  2. Triage: core team assesses: is this generalizable? Does something similar exist? What's the priority?
  3. Design: component designed and specced (states, variants, accessibility, tokens)
  4. Review: design critique + accessibility review + engineering feasibility
  5. Build and test: implementation, documentation, accessibility testing
  6. Release: versioned release with changelog entry
  7. Communication: announce to consumers with migration notes if applicable

Versioning

Use semantic versioning (semver) as the communication contract:

Version typeWhen 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
Show full SKILL.md (236 more words)Show less

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

© Owl-Listener, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in design-systems/skills/design-system-governance of Owl-Listener/designer-skills.

Open the folder on GitHubat commit 9a6930c

Used in 1 other repository

We found 2 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in Owl-Listener/designer-skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Design System Governance next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Design System Governance compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Design System Governance this skillOwl-Listener/designer-skills2.9k1 repos~1.3kAutomated safety check: PassMIT
Jira Implement Taskcommercetools/ui-kit154—~1.6kAutomated safety check: NotesMIT
Impeccablebestofjs/bestofjs3.1k26 repos~2.6kAutomated safety check: PassMIT
Figma Design System Builderwarpdotdev/warp65k2 repos~4.4kAutomated safety check: PassAGPL-3.0
Figma use_figma Plugin API Ruleswarpdotdev/warp65k4 repos~4.4kAutomated safety check: PassAGPL-3.0
UI StylingOhh-889/skyroc79513 repos~2.5kAutomated safety check: PassMIT

Similar skills

  • Jira Implement Task

    commercetools/ui-kit

    Fetch Jira ticket, create branch, implement changes, commit, push, open PR.

    154 GitHub stars~1.6k tokensUpdated 8 days ago
    DevelopmentAuto-check: notes

  • Impeccable

    bestofjs/bestofjs

    A skill your agent uses when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a…

    3.1k GitHub starsUsed in 26 repos~2.6k tokens
    Frontend & DesignAuto-check passed

  • Figma Design System Builder

    warpdotdev/warp

    Builds or updates a design system in Figma from a codebase in ordered phases: discovery, variables and tokens, components, theming and documentation, with checkpoints.

    65k GitHub starsUsed in 2 repos~4.4k tokens
    Frontend & DesignAuto-check passed

  • Figma use_figma Plugin API Rules

    warpdotdev/warp

    Required groundwork before any use_figma call: the rules and reference files for running JavaScript in a Figma file through the Plugin API without common failures.

    65k GitHub starsUsed in 4 repos~4.4k tokens
    Frontend & DesignAuto-check passed

  • UI Styling

    Ohh-889/skyroc

    Create beautiful, accessible user interfaces with shadcn/ui components (built on Radix UI + Tailwind), Tailwind CSS utility-first styling, and canvas-based visual designs.

    795 GitHub starsUsed in 13 repos~2.5k tokens
    Frontend & DesignAuto-check passed

  • Shadcn

    supabase/evals

    Official

    Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI.

    145 GitHub starsUsed in 43 repos~4.5k tokens
    Frontend & DesignAuto-check passed

More from Owl-Listener/designer-skills

All 107 skills in this repo

  • A B Test Design

    Owl-Listener/designer-skills

    Design an A/B experiment — hypothesis, variants, primary metric, and sample size.

    2.9k GitHub starsUsed in 1 repo~472 tokens
    Auto-check passed

  • Accessibility Test Plan

    Owl-Listener/designer-skills

    Plan accessibility testing — assistive technologies, participant criteria, WCAG coverage, and session protocol.

    2.9k GitHub starsUsed in 1 repo~478 tokens
    Auto-check passed

  • Aesthetic Usability

    Owl-Listener/designer-skills

    Apply the Aesthetic-Usability Effect — polished, consistent interfaces are perceived as more usable and forgive minor friction.

    2.9k GitHub starsUsed in 1 repo~678 tokens
    Auto-check passed

  • Affinity Diagram

    Owl-Listener/designer-skills

    Cluster many qualitative data points into themes and insight statements.

    2.9k GitHub starsUsed in 1 repo~520 tokens
    Auto-check passed

  • Animation Principles

    Owl-Listener/designer-skills

    Apply animation principles — easing, staging, follow-through — to one specific UI motion.

    2.9k GitHub starsUsed in 1 repo~492 tokens
    Auto-check passed

  • Business Design

    Owl-Listener/designer-skills

    Read financials, map competitive landscapes, and argue design decisions in the language of value.

    2.9k GitHub starsUsed in 1 repo~1.1k tokens
    Auto-check passed

Categories

Questions about Design System Governance

What does Design System Governance do?

Define how the system evolves — contribution model, versioning, deprecation, and change management. Design System Governance is an agent skill from Owl-Listener/designer-skills. Define how the system evolves — contribution model, versioning, deprecation, and change management.

When should I use Design System Governance?

Design System Governance fits situations like: multiple teams contribute; tasks that involve Design systems; tasks that involve Git workflow.

How do I install Design System Governance in Claude Code?

Run `npx skills add Owl-Listener/designer-skills --skill design-system-governance -a claude-code`. Or copy the skill folder (design-systems/skills/design-system-governance in Owl-Listener/designer-skills) into .claude/skills/design-system-governance in your project. Claude Code loads it when a task matches its description.

How do I install Design System Governance in Codex?

Run `npx skills add Owl-Listener/designer-skills --skill design-system-governance -a codex`. Or copy the skill folder (design-systems/skills/design-system-governance in Owl-Listener/designer-skills) into .agents/skills/design-system-governance in your project. Codex loads it when a task matches its description.

Can I use Design System Governance in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Owl-Listener/designer-skills --skill design-system-governance -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/design-system-governance, .gemini/skills/design-system-governance, .github/skills/design-system-governance and .opencode/skills/design-system-governance in your project.

What does Design System Governance need to run?

SKILL.md names no scripts, command-line tools or credentials: Design System Governance is instructions for the agent only.

Does Design System Governance access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Design System Governance safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Design System Governance use?

Design System Governance is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Design System Governance use?

About 1.3k tokens (SKILL.md is roughly 5.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Design System Governance?

Skills that share tags, products or a category with Design System Governance: Jira Implement Task (commercetools/ui-kit, 154 stars), Impeccable (bestofjs/bestofjs, 3.1k stars), Figma Design System Builder (warpdotdev/warp, 65k stars) and Figma use_figma Plugin API Rules (warpdotdev/warp, 65k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Design System Governance?

Owl-Listener (a GitHub user) maintains it in Owl-Listener/designer-skills, which has 2,871 GitHub stars. The repository holds 107 skills in this directory. The repository was last updated on September 5, 2026.

Source: Owl-Listener/designer-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.