governance

Applies SemVer versioning, contribution, and deprecation rules to design system changes.

Updated Jul 20, 2026
One-click install
npx skills add https://github.com/idy-00/paytrack --skill governance-idy-00
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: governance
Source: https://github.com/idy-00/paytrack/tree/main/backend/.agents/skills/governance
Command: npx skills add https://github.com/idy-00/paytrack --skill governance-idy-00

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Design systems fragment as they grow: tokens get renamed without notice, components ship without quality review, and breaking changes land without migration paths. This Skill enforces a consistent governance process so every change is versioned, reviewed, and communicated. ## Core Features & Use Cases - SemVer Classification: Classifies changes as major (breaking renames/removals), minor (additive tokens/components/variants), or patch (fixes and doc tweaks). - Contribution Workflow: Gates new components and tokens behind a real-need check (used in at least 2 places) and a promotion path from product to candidate to core. - Deprecation Policy: Requires a reason, replacement, removal version, migration map, and at least one minor cycle of support before removal in a major release. - Use Case: A designer wants to deprecate an old color token. The Skill walks through marking it deprecated with a replacement, adding a migration table, keeping it working for a minor cycle, and logging the changelog entry. ## Quick Start Ask the assistant to govern a design system change, for example: classify this component rename and set up its deprecation and changelog entry.

Frequently Asked Questions about governance

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I version design system changes with SemVer?

Classify the change by impact: major for breaking changes like renamed or removed tokens and props, minor for additive changes like new tokens, components, or optional props, and patch for fixes such as contrast tweaks or doc updates. Every change gets a SemVer level plus a changelog entry.

How do I deprecate a design token or component safely?

Mark it deprecated with a reason, a replacement, and a removal version. Keep it working for at least one minor cycle, provide a migration map, and only remove it in a major release.

When should a new component be added to a design system?

Only when it serves a real, repeated need in at least two places. It then follows a promotion path from product to candidate to core, and must meet the full quality bar including 8-state coverage, accessibility, and token mapping.

What counts as a breaking change in a design system?

A breaking change is any renamed or removed token or prop, or a changed component anatomy or default value. These require a major version bump and, for removals, a deprecation window with a migration table.

What are the limitations of a governance-only workflow?

Governance defines rules and process but does not design or implement components itself. It depends on separate component quality rules and token validation scripts, so it works best alongside design and engineering skills rather than replacing them.