design-system-governance
Define how a design system evolves — contribution models, versioning, change management, and deprecation.
What this skill does
# 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 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
Related in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.