Component Library Governance: Contribution, Versioning, and Deprecation
Defines the complete governance model for a design system or component library, including contribution workflows, support SLAs, semantic versioning, and component lifecycle management.
Establish a sustainable governance model for a component library that balances evolution speed with stability for consumer teams, with clear processes for contribution, review, publication, and deprecation.
At a glance
Access
Free prompt
Open to copy without upgrading.
Prompt objective
Establish a sustainable governance model for a component library that balances evolution speed with stability for consumer teams, with clear processes for contribution, review, publication, and deprecation.
Real use case
A mid-sized e-commerce platform with 8 product squads launched a design system 2 years ago but never defined governance. Result: 3 squads built incompatible custom buttons, 2 versions of the design system coexist in production, and the design team has no framework for handling daily requests for new components.
Customize these fields first
Replace the placeholders with your own context before you run the prompt. That usually improves the first output more than adding more instructions later.
Prompt
Define the complete governance model for the [LIBRARY NAME] component library at [COMPANY NAME], which serves [NUMBER] product teams with [NUMBER] published components.\\\\\\\\n\\\\\\\\n**Current state:**\\\\\\\\n- Consumer teams: [NUMBER]\\\\\\\\n- Published components: [NUMBER]\\\\\\\\n- Active maintainers: [NUMBER]\\\\\\\\n- Current version: [VERSION]\\\\\\\\n- Most frequent issues: [LIST]\\\\\\\\n\\\\\\\\n**Part 1 — Contribution Model:**\\\\\\\\n\\\\\\\\n**Governance structure:**\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\n[DESIGN SYSTEM CORE TEAM] — maintainers\\\\\\\\n |\\\\\\\\n[CHAPTER LEADS] — squad representatives\\\\\\\\n |\\\\\\\\n[CONTRIBUTORS] — any developer or designer\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\n\\\\\\\\n**4 contribution pathways:**\\\\\\\\n\\\\\\\\n**Path 1 — Bug fix (simplest):**\\\\\\\\n1. Open issue in repository using bug template\\\\\\\\n2. PR with fix\\\\\\\\n3. Review by 1 maintainer\\\\\\\\n4. Merge and patch release (x.x.PATCH)\\\\\\\\n- SLA: maintainer must review within 48 hours\\\\\\\\n\\\\\\\\n**Path 2 — Improve existing component:**\\\\\\\\n1. Proposal issue describing problem and solution\\\\\\\\n2. Quick alignment (async or 30min with maintainer)\\\\\\\\n3. Implement per Design System Docs\\\\\\\\n4. PR with tests and stories\\\\\\\\n5. Review by 2 maintainers + 1 designer\\\\\\\\n6. Merge and minor release\\\\\\\\n- SLA: review within 5 business days\\\\\\\\n\\\\\\\\n**Path 3 — New component:**\\\\\\\\n1. RFC (Request for Comments): 1-page doc explaining:\\\\\\\\n - Problem it solves\\\\\\\\n - Alternatives considered\\\\\\\\n - Proposed API (props, variants, states)\\\\\\\\n - Usage examples in 3 different contexts\\\\\\\\n2. Open review for 1 week (anyone can comment)\\\\\\\\n3. Core Team decision (approved / rejected / changes requested)\\\\\\\\n4. Implementation with mandatory pair design+dev\\\\\\\\n5. PR with: component + tests + stories + docs + a11y checklist\\\\\\\\n6. Review by 3 maintainers\\\\\\\\n7. Publish as minor version with preview period\\\\\\\\n- SLA: first response to RFC within 5 business days\\\\\\\\n\\\\\\\\n**Path 4 — Breaking change:**\\\\\\\\n1. Detailed RFC with documented migration\\\\\\\\n2. Review by all affected chapter leads\\\\\\\\n3. Vote: unanimity from Core Team\\\\\\\\n4. Mandatory codemod for automated migration\\\\\\\\n5. Preview for 4 sprints before major release\\\\\\\\n6. Communication to all teams with 30 days notice\\\\\\\\n- SLA: decision within 10 business days\\\\\\\\n\\\\\\\\n**Part 2 — Semantic Versioning:**\\\\\\\\n\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\nMAJOR.MINOR.PATCH\\\\\\\\n\\\\\\\\nMAJOR: Breaking changes (API changed, props renamed, component removed)\\\\\\\\nMINOR: New components or new optional props (backward-compatible)\\\\\\\\nPATCH: Bug fixes, performance improvements, docs (backward-compatible)\\\\\\\\n\\\\\\\\nExamples:\\\\\\\\n1.5.3 → 1.5.4: Bug fix on Button\\\\\\\\n1.5.3 → 1.6.0: New Stepper component added\\\\\\\\n1.5.3 → 2.0.0: Design tokens renamed (breaking change)\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\n\\\\\\\\n**Version support policy:**\\\\\\\\n| Version | Status | Support | Bug fixes | Security |\\\\\\\\n|---------|--------|---------|-----------|----------|\\\\\\\\n| v3.x (current) | Active | Full | Yes | Yes |\\\\\\\\n| v2.x | Maintenance | Critical bugs only | Yes | Yes |\\\\\\\\n| v1.x | EOL | None | No | No |\\\\\\\\n\\\\\\\\n- Major versions receive full support for 18 months after the next major release\\\\\\\\n- Announce EOL 6 months in advance\\\\\\\\n\\\\\\\\n**Part 3 — Component Lifecycle:**\\\\\\\\n\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\n[PROPOSAL] → [ALPHA] → [BETA] → [STABLE] → [DEPRECATED] → [REMOVED]\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\n\\\\\\\\n**Stage definitions:**\\\\\\\\n\\\\\\\\n- **Alpha**: Available to early-adopter squads only. May change without notice.\\\\\\\\n - Badge: \\\\\\\\\\\\\\\\\\\\\\\`@alpha\\\\\\\\\\\\\\\\\\\\\\\` in documentation\\\\\\\\n - No support SLA\\\\\\\\n - Maximum of 2 sprints in this state\\\\\\\\n\\\\\\\\n- **Beta**: API frozen, but feedback still welcome.\\\\\\\\n - Badge: \\\\\\\\\\\\\\\\\\\\\\\`@beta\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\n - Bug fix SLA: 5 business days\\\\\\\\n - Maximum of 4 sprints in this state\\\\\\\\n\\\\\\\\n- **Stable**: Production-ready. Backward compatibility guaranteed within minor versions.\\\\\\\\n - No badge\\\\\\\\n - Critical bug SLA: 24 hours, others: 5 business days\\\\\\\\n\\\\\\\\n- **Deprecated**: Will be removed in next major version.\\\\\\\\n - Badge: \\\\\\\\\\\\\\\\\\\\\\\`@deprecated\\\\\\\\\\\\\\\\\\\\\\\` + link to alternative\\\\\\\\n - Console warning in dev mode\\\\\\\\n - Minimum of 2 sprints preview before removal\\\\\\\\n - Codemod available for migration\\\\\\\\n\\\\\\\\n- **Removed**: No longer exists in the package.\\\\\\\\n - Documented in BREAKING_CHANGES.md\\\\\\\\n - Codemod still available for 6 months\\\\\\\\n\\\\\\\\n**Part 4 — Communication and Documentation:**\\\\\\\\n\\\\\\\\n**Automated changelog (Conventional Commits):**\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`bash\\\\\\\\n# Commits must follow:\\\\\\\\nfeat(Button): add ghost variant → minor\\\\\\\\nfix(Input): fix focus on Safari → patch\\\\\\\\nfeat!(Modal): rename 'show' prop → major\\\\\\\\n\\\\\\\\n# Generate changelog automatically:\\\\\\\\nnpx conventional-changelog -p angular -i CHANGELOG.md -s\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\n\\\\\\\\n**Communication channels:**\\\\\\\\n- Slack #design-system: announcements and daily support\\\\\\\\n- Slack #design-system-releases: releases only (all devs subscribe)\\\\\\\\n- Monthly office hours: 1h monthly, open to all\\\\\\\\n- Public RFCs: GitHub Discussions\\\\\\\\n- Roadmap: Notion/Linear public to all teams\\\\\\\\n\\\\\\\\n**Part 5 — Library Health Metrics:**\\\\\\\\n- Adoption: % of library components vs. custom components per squad\\\\\\\\n- Contribution: external PRs per month\\\\\\\\n- Satisfaction: NPS from consumer teams (quarterly)\\\\\\\\n- Open bugs per component\\\\\\\\n- Time to resolve by category (bug/feature)\\\\\\\\n- Bundle size per version (regression alert if growth > 5% without justification)\\\\\\\\n\\\\\\\\n**Deliverables:** governance document in Notion + RFC template + issue templates + configured CODEOWNERS.
Open directly in an AI — the text is pre-filled:
How to use this prompt
- 1Replace the key placeholders first: LIBRARY NAME, COMPANY NAME, NUMBER, VERSION.
- 2Replace any bracketed placeholders like [this] with your own context.
- 3Add extra background information when you want more tailored results.
- 4Combine multiple prompts in one conversation when you need a richer output.
- 5Save your best-performing prompts so they are easy to reuse later.
Next best step
Open the guide first, then branch only if you still need more.
A starter guide to the first prompt categories and patterns worth using when you need better output without prompt guesswork.
If this prompt is close but not quite right, generate variants next. If the job is recurring, move into the course library after the guide.
Related prompts
View allDesign Tokens System: Complete Architecture for Multi-Platform Products
Design a 3-layer design tokens system (primitives, semantics, component-specific) for products running on web, iOS, and Android, with Figma-to-code synchronization pipeline.
Best for
Create a complete design tokens architecture that unifies the visual language of a multi-platform product, eliminates inconsistencies between design and development, and enables theming (light/dark mode, white-label) without code duplication.
Mobile-First Accessibility Audit with WCAG 2.2 and LBI
Complete accessibility audit framework for mobile-first applications, covering WCAG 2.2, Brazilian Law on Inclusion (LBI), and optimizations specific to touch screens and virtual keyboards.
Best for
Execute a comprehensive mobile-first accessibility audit that identifies all access barriers for users with visual, motor, auditory, and cognitive disabilities, with a prioritized remediation plan based on impact and implementation effort.
Design Review Checklist for High-Fidelity Handoff Between Design and Development
Creates a comprehensive design review checklist to ensure specs delivered to development are complete, consistent, and unambiguous—reducing post-implementation review cycles.
Best for
Standardize the design-to-development handoff process with a structured checklist covering spec completeness, design system consistency, edge cases, accessibility, and responsiveness—eliminating rework caused by incomplete specifications.
User Research Synthesis: From Raw Data to Actionable Insight
Complete framework for analyzing and synthesizing qualitative research data (interviews, usability tests, diaries) into prioritized insights and actionable design recommendations for the product team.
Best for
Transform raw qualitative research data into clear, prioritized insights that drive concrete product decisions, using affinity diagramming, job stories, and impact vs. effort techniques to align design, product, and business.
Explore other prompt categories
Move sideways into adjacent libraries when the current category is not the full answer.
Free browsing stays open. Premium prompts unlock the reusable workflow layer.
Use the guides and role paths to validate the job first. Upgrade when you want the full prompt text, editable premium prompts, and the surrounding course paths in one place.
Free access
- Browse guides, role paths, and category pages.
- Preview prompts before you decide to upgrade.
- Find the right starting point without friction.
Membership access
- Unlock premium prompts and the full copy text.
- See more workflow paths and course connections.
- Keep the reusable templates in one place.
