governance
This governance skill enforces consistency in design system evolution through semantic versioning, contribution workflows, and deprecation policies. Use it when adding, promoting, or deprecating components or tokens; determining version bumps; establishing contribution processes; or preventing system fragmentation through uncontrolled changes.
git clone --depth 1 https://github.com/plugin87/ux-ui-agent-skills /tmp/governance && cp -r /tmp/governance/.claude/skills/governance ~/.claude/skills/governanceSKILL.md
# Skill: Governance Keep the system consistent as it grows. Apply versioning, contribution, and deprecation rules. ## Steps 1. Read `workflows/governance.md` (SemVer table, contribution workflow, deprecation policy, change comms). 2. Classify the change: **major** (breaking — renamed/removed token or prop, changed anatomy/default), **minor** (additive — new token/component/variant/optional prop), **patch** (fix — contrast/bug/doc/value tweak in tolerance). 3. For a **new** component/token: confirm it serves a real, repeated need (≥ 2 places) before promoting product → candidate → core. Design it to the full quality bar (`.claude/rules/components.md` → Component Quality Bar). 4. For a **deprecation**: mark with reason + replacement + removal version; keep working ≥ 1 minor cycle; provide a migration map (`design-systems/crosswalk.md` style); remove only in a major. 5. Wire any new file into `CLAUDE.md` (File Reference Map + relevant table/router) and add a changelog entry. ## Verification (definition of done) - Change has a SemVer level **and** a changelog entry. - Removals have a deprecation window, a replacement, and a migration table. - New spec meets the 8-state + a11y + token-mapping bar and is reachable via the router. - `python3 scripts/validate_tokens.py` passes; contrast re-checked if colors changed.
Audit a UI or design against WCAG 2.2 AA/AAA and ARIA patterns, returning criterion-referenced findings with severity and specific fixes. Use when the user wants an accessibility check, contrast verification, keyboard/screen-reader review, or wants to confirm a component meets POUR.
Apply a visual direction — an archetype (high-end agency, editorial minimal, brutalist, soft-SaaS, dark-tech) or one of 138 named design systems (apple, linear-app, stripe, vercel, notion, material, shadcn, spotify, tesla…) — by resolving it into the token system. Use when the user wants a specific look/vibe/brand feel, or asks to make a design feel premium/expensive/non-generic.
Generate a complete, accessible brand design system from a brief — primitive → semantic → component DTCG tokens (color, type, spacing, radius, shadow, motion), light + dark, plus a single theme.css — verified for WCAG. Use when the user wants a from-scratch brand/design foundation, a new palette + type system, or a themeable token kit for a product.
Adversarial design critique of the current work — render it, look at it, and argue for rejection. Run after the gates are green, never instead of them.
Generate production-ready, accessible, token-driven component code for ANY framework — React+Tailwind, Next.js, SwiftUI, Vue, Svelte, Angular, Solid, Web Components/Lit, React Native, Flutter, Jetpack Compose, vanilla CSS, or CSS-in-JS. Use when the user wants working UI code for a component or screen in a specific stack.
Design a UI component spec to the house quality bar — anatomy, variants, sizes, the 8 states, token mapping, and accessibility. Use when the user wants to design or document a component (button, input, tabs, toast, combobox, date picker, modal, etc.) at the spec level before or alongside code. For generating framework code, use design-code.
Adversarial senior design critic. Renders the work, looks at it, and argues for rejection. Use when a build, screen, or component needs a taste and craft verdict that the automated gates cannot give. Runs after the gates are green, never instead of them.
Set up or run design QA gates — token + hardcoded-value lint, automated a11y (axe), contrast, visual regression across variants/states/themes/RTL, and the manual a11y checklist. Use when the user wants CI quality gates, to prevent design regressions, or to QA a component/screen before shipping.