Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jpoindexter/design-system-governance
Reference-grade operating manual for running a design system as a versioned product — operating models, contribution and release process, Figma↔code token parity, documentation, adoption metrics, and the anti-patterns that kill systems.
Passed 22 of 23 test cases with the skill, and 19 of 23 without it.
and 1 more in the full report
3 fixed19 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
A product squad requests a highly specialized financial chart widget that will only ever be used in their specific dashboard feature. What are the four standard triage outcomes for design system intake requests, and which outcome applies to this request?
| Checked | Without skill | With skill |
|---|---|---|
| Lists the four triage outcomes as accept, defer, redirect, and decline. | Missed | Passed |
| Recommends declining or deferring the request as a local one-off feature. | Missed | Passed |
The instructions your model reads when the skill loads.
Governance is the difference between a component library and a design system. A library is a folder of components; a system is a product with users (your product teams), a roadmap, a release cadence, owners, and rules for change. This skill is the operating manual: how to structure ownership, run contribution, ship versions, keep design and code in sync, document, and measure adoption — without over-building before anyone uses it.
First principle. A design system is infrastructure for other people's work. Every decision is graded by one question: does this make product teams ship faster, more consistently, and more accessibly? If a governance rule does not, cut it.
It is not a UI kit. It is the full stack below; skipping layers is the #1 reason systems stall.
| Layer | What it is | Lives in |
|---|---|---|
| Principles | The values that resolve arguments (e.g. "accessible by default", "boring on purpose") | Docs site, README |
| Tokens | Named design decisions — color, space, type, radius, motion, elevation | JSON source → Figma variables + code |
| Components | Coded, accessible, themeable UI primitives + their Figma equivalents | Code repo + Figma library |
| Patterns | Reusable compositions solving recurring problems (forms, empty states, data tables) | Docs + recipes |
| Guidelines | Content/voice, a11y, layout, do/don't usage rules | Docs |
| Tooling | Token pipeline, linters, CI, visual tests, release automation | Repo + CI |
| People & process | Owners, contribution model, intake, support, RFCs | This document |
Maturity model — diagnose honestly before choosing governance weight:
| Stage | Symptom | Governance need |
|---|---|---|
| 0 Chaos | Every team reinvents buttons; 12 grays in prod | None yet — just inventory the drift |
| 1 Library | Shared components exist, no tokens, no versioning | Add semver + a changelog |
| 2 Managed | Tokens, docs, releases, an owner | Add contribution model + adoption tracking |
| 3 Integrated / Holistic | Design↔code parity, tokens are single source of truth, adoption measured, multi-brand theming | Federated contribution, deprecation policy, ROI reporting |
Match governance to stage. A 3-person startup at Stage 1 does not need RFCs; a 200-engineer org at Stage 3 dies without them.
Who owns and builds the system. Pick deliberately — the wrong model for your org size is a slow failure.
| Model | How it works | Best for | Failure mode |
test cases passed, vs 19 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.