Skip to main content

govern-a-design-system

Govern a shared design system through accountable contribution, release, adoption, exception, and retirement. Use when many teams depend on common interface decisions and unmanaged change could create product, accessibility, or delivery risk.

Source facts

Repository
protosphinx/sphinxstack
Last source activity
July 29, 2026 at 13:55
Detected SKILL.md language
English
Stars
3
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
govern-a-design-system
category
design
description
Govern a shared design system through accountable contribution, release, adoption, exception, and retirement. Use when many teams depend on common interface decisions and unmanaged change could create product, accessibility, or delivery risk.
# govern-a-design-system ## When to use - Use for a multi-team system with shared code, design assets, tokens, documentation, or standards. - Use normal component ownership for a small local library with no cross-team governance risk. ## Preconditions - Confirm sponsor, maintainers, consumers, decision authority, funding, repositories, release channels, and product obligations. ## Procedure 1. Define system scope, user outcomes, principles, supported platforms, service promise, and ownership model. 2. Build a consumer inventory and dependency record with versions, criticality, contacts, and adoption evidence. 3. Establish contribution governance covering intake, problem evidence, design and engineering review, accessibility review, and decision records. 4. Define maturity states, acceptance criteria, release evidence, semantic versioning, distribution, and support. 5. Create change classification for compatible, breaking, urgent, experimental, deprecated, and retired work. 6. Govern exceptions with scope, rationale, compensating controls, owner, exception expiry, and convergence plan. 7. Provide communication, migration, training, office hours, and response targets proportional to capacity. 8. Measure adoption, duplication, quality, accessibility, satisfaction, support burden, and time to change. 9. Rehearse a breaking change, urgent fix, failed release, unavailable maintainer, and consumer rollback. 10. Review funding, roadmap, decision rights, and system health with consumers on a fixed cadence. ## Failure plan - Do not force adoption when the system cannot meet a consumer's evidenced need. - Stop releases on unowned breaking impact, failed accessibility gates, or unavailable rollback. - Never let an exception become permanent through silent renewal. ## Done - A governance charter records scope, ownership, decision rights, and service promise - A contribution and release evidence package verifies quality and compatibility - An exception register and retirement record prove bounded divergence - Consumer health review and failure rehearsal are recorded
View on GitHub