design-system-ops

Generate a CI/CD pipeline for design system quality checks

Generate a migration codemod with tests and rollback plan

Audit your component library inventory

Generate an AI-optimised component description

Detect where teams are diverging from the system

Comprehensive design system health sweep

Quarterly governance review package

Plan and execute a design system migration

Pre-release validation pipeline for a component

Benchmark your design system across 12 scored dimensions

Score your design system's overall health

Audit your design token architecture

Generate a visual dashboard from audit findings

Run an accessibility audit on a specific design system component. Trigger when someone says: accessibility check, a11y audit, WCAG compliance, is this accessible, check accessibility, does this meet WCAG, screen reader support, keyboard navigation check, or anything about auditing the accessibility of a specific component.

Produce a design system adoption report separating coverage from actual adoption, with trend direction and risk flags. Trigger when someone says: adoption report, how much is the system being used, usage metrics, adoption status, coverage report, which teams are using the system, who's not using the system, or anything about measuring or reporting on how widely the design system is being used.

Generate AI-optimised text descriptions for components, formatted for Figma's MCP server and LLM consumption. This produces prose descriptions in a six-section format (purpose, props, anti-patterns, composition, accessibility, examples), NOT JSON schemas or structured data files. Trigger when someone says: write component description for AI, Figma MCP description, write the description for Claude to read, six-section description, describe this component for AI, or anything about writing text that makes components legible to LLMs. Do NOT trigger for JSON metadata schemas, structured constraint files, or programmatic tooling data — use metadata-schema-generator for those.

Transform audit findings into sprint-ready work items with effort estimates, acceptance criteria, and stakeholder-friendly rationale. This converts existing findings into tickets, NOT the process for contributing new components to the system. Trigger when someone says: generate backlog items, create tickets from audit, turn findings into work items, sprint planning from audit, create issues from report, backlog from diagnostic, or anything about converting audit output into actionable work items. Do NOT trigger for defining the contribution process or guidelines for new components — use contribution-workflow for that.

Produce a communication package for a design system change — release notes, migration guide, and team announcement. This produces communication artefacts for changes that have already been decided, NOT the deprecation lifecycle itself. Trigger when someone says: communicate this change, breaking change announcement, how do I tell teams about this, release notes, change log, write the announcement, or anything about communicating an update, release, or breaking change to consuming teams. Do NOT trigger for planning or executing a deprecation — use deprecation-process for that, which includes its own communication plan as part of the full lifecycle.

Generate CI/CD pipeline configurations that automate design system quality checks — token validation, component linting, visual regression, accessibility scanning, and release gating. Produces ready-to-use pipeline files for GitHub Actions, GitLab CI, CircleCI, or Bitbucket Pipelines, configured to enforce the standards that audit skills check manually. Trigger when someone says: set up CI for the design system, automate these checks, add pipeline for tokens, create GitHub Action for design system, CI/CD for components, automate the release process, continuous integration for design system, how do I automate what the audit found, quality gates in CI, or anything about automating design system quality checks in a pipeline. Do NOT trigger for running a manual audit — use the specific audit skill for that. Do NOT trigger for generating a release checklist — use change-communication for that.

Generate a pre-computed component index from a design system codebase — YAML infrastructure files containing a component inventory, relationship graph, and summary statistics that AI agents and MCP servers consume. This produces machine-readable index files in .ai/index/, NOT a health report or quality assessment. Trigger when someone says: index my codebase, build a relationship graph, create a component map, codebase index, what depends on what, dependency graph, map component relationships, or anything about producing queryable infrastructure files for AI agents or developer tooling. Do NOT trigger for component health assessments, quality scores, or audit reports — use component-audit for those.

Generate codemods (automated code transformation scripts) for design system migrations — token renames, component API changes, prop deprecations, and import path updates. Produces ready-to-run jscodeshift or custom AST transform scripts that safely apply changes across consuming codebases. Trigger when someone says: generate a codemod, automate this migration, write a transform script, bulk rename tokens, auto-migrate components, jscodeshift for this change, create a migration script, update all imports, rename this prop everywhere, or anything about automating code changes across consumers of a design system. Do NOT trigger for planning the deprecation process — use deprecation-process for that. Do NOT trigger for writing release notes about a change — use change-communication for that.

Audit component APIs for consistency, breaking changes, TypeScript coverage, and contract compliance across a component library. Trigger when someone says: component prop review, verify component types are exported, component API audit, check our component interfaces, are our props consistent, API consistency check, prop naming review, breaking change detection, or anything about checking whether component APIs are structurally sound and consistent across the library.

Audit a design system's component library for health, producing a findings-based assessment of usage, complexity, duplication, and coverage gaps with actionable recommendations. This produces a deep, single-dimension audit of the component library, NOT a cross-cutting system health assessment. Trigger when someone says: audit my components, component health, what components do I have, unused components, component coverage, component review, assess my library, or anything about evaluating the quality and health of a component library. Do NOT trigger for building machine-readable index files or dependency graphs for AI agents — use codebase-index for those. Do NOT trigger for a holistic health summary — use system-health for that.

Build queryable decision trees that help agents and teams choose between components — structured YAML files mapping user intents to the correct component through a sequence of narrowing questions. This produces selection logic for choosing BETWEEN components, NOT usage guidelines for a single component. Trigger when someone says: component decision tree, which component should I use, help me choose between, selection guide, decision framework, modal vs dialog, intent-to-component mapping, or anything about creating structured logic for picking the right component from alternatives. Do NOT trigger for usage guidance on a specific component — use usage-guidelines for that.

Generate a context engine — seven structured blueprint files (UX, UI, content, accessibility, ethical, technical, business intelligence) that encode everything an AI agent needs to work with a design system. This produces YAML infrastructure in .ai/context-engine/, NOT a health score or quality assessment. Trigger when someone says: build a context engine, create a system brain, build the seven blueprints, context engine, blueprint stack, encode design system knowledge for AI, make our system AI-navigable, or anything about creating structured knowledge files that AI agents load to understand the system. Do NOT trigger for scoring or assessing system health — use system-health for that.

Create or document a contribution workflow for a design system — the multi-stage process for evaluating, accepting, and shepherding new contributions through to publication. Trigger when someone says: how should someone contribute, contribution process, adding a new component, contribution guidelines, what's the process for adding something, how do we handle contributions, or anything about the process of bringing new work into the design system. Do NOT trigger for converting audit findings into backlog tickets — use backlog-generator for that.

Create a structured narrative record documenting why a design system decision was made — the context, options considered, trade-offs, and rationale. This produces a human-readable decision document, NOT machine-executable rules or constraint files. Trigger when someone says: document this decision, record why we chose, ADR, architecture decision record, capture this decision, why did we pick, what was the reasoning, or anything about preserving the narrative behind a specific design system choice. Do NOT trigger for encoding governance policies as machine-checkable rules — use governance-encoder for that.

Plan and execute the full deprecation lifecycle for a design system component, token, or pattern — including timeline, migration paths, communication plan, and multi-phase removal. Trigger when someone says: deprecate a component, remove a component, sunset this pattern, phase out these tokens, retire this variant, replace this with, or anything involving removing or replacing something from the design system. Do NOT trigger for communicating non-deprecation changes like new releases or feature updates — use change-communication for those.

Check alignment between a specific design specification and its code implementation — a focused, single-component or single-screen comparison. Trigger when someone says: does this match the design, check implementation, design code alignment, what's different between the design and the build, spec check, implementation review, or anything about comparing a designed component or screen to its coded equivalent. Do NOT trigger for system-wide drift detection across multiple components or teams — use drift-detection for that.

Create an onboarding guide for a designer joining a team that uses a design system. Trigger when someone says: onboard new designer, getting started guide, new team member guide, onboarding documentation, first day with the system, new designer guide, or anything about helping a designer new to the team or the design system get up to speed.

Identify where a design system has diverged from its original intent across the whole system — components implemented differently to spec, tokens overridden locally, patterns forked across teams. This is a system-wide sweep for divergence patterns, NOT a single-component spec comparison. Trigger when someone says: find drift, where has the system diverged, design code inconsistency, what's out of sync, where are teams going off-system, component drift, or anything about identifying gaps between design system intent and actual implementation. Do NOT trigger for checking one specific component against its design spec — use design-to-code-check for that.

Create an onboarding guide for an engineer joining a team that consumes the design system. Trigger when someone says: onboard new engineer, developer getting started guide, new engineer guide, engineering onboarding, first day for developers, frontend onboarding, or anything about helping an engineer new to the team get up to speed with the design system.

Audit Figma variable collections against token architecture best practices. Trigger when someone says: audit my Figma variables, check my Figma tokens, are my variables structured correctly, Figma variable health, review my variable collections, variable naming check, or anything about auditing the quality or structure of Figma variables.

Convert governance policies into machine-executable JSON constraint files that AI agents and CI pipelines validate against automatically. This produces rule engine files in .ai/governance/, NOT narrative decision records or documentation. Trigger when someone says: encode governance rules, governance as code, automate governance, rule engine, machine-executable constraints, enforce rules automatically, constraint definitions, or anything about converting human-readable policies into structured rules that tools check programmatically. Do NOT trigger for documenting why a decision was made or recording the reasoning behind a choice — use decision-record for those.

Generate structured JSON metadata schemas for design system components — machine-readable constraint definitions that encode props, behavioural rules, composition constraints, prohibited combinations, and accessibility contracts as programmatic data. This produces JSON files for tooling (MCP servers, linters, code generators, test frameworks), NOT text descriptions for humans or Figma. Trigger when someone says: generate metadata schema, JSON schema for components, component contract as JSON, structured metadata for tooling, prop constraints as data, machine-readable component rules, or anything about producing JSON/structured data that tools consume programmatically. Do NOT trigger for Figma descriptions, component documentation, or AI-readable text — use ai-component-description for those.

Audit a design system's naming conventions across components, tokens, and patterns. Trigger when someone says: naming conventions, audit component names, are my names consistent, naming problems, naming review, inconsistent names, fix our naming, review naming, or anything about the quality or consistency of names in a design system.

Write documentation for a design system pattern — a multi-component recipe covering use cases, anti-patterns, composition, and related patterns. Patterns span multiple components working together (e.g. a form pattern, a data table pattern). Trigger when someone says: document this pattern, write the pattern page, usage pattern, when to use this, pattern guidelines, document how this works, or anything about creating documentation for a reusable UI pattern rather than a single component. Do NOT trigger for writing usage guidelines for a single named component — use usage-guidelines for that.

Produce a structured look-back after a major release or deprecation — capturing what the plan got right, what it missed, and what to do differently. Trigger when someone says: release retrospective, post-release review, what went wrong with the release, how did the deprecation go, release post-mortem, retro on the migration, or anything about reviewing how a release or deprecation actually went compared to the plan.

Validate token files against DTCG 2025.10, Style Dictionary, or custom schemas. Trigger when someone says: validate token JSON, check my token files for errors, schema validation for tokens, are my token files valid, DTCG compliance check, validate token format, or anything about checking whether token files are structurally correct before they break builds.

Persist and recall findings across skill runs within and between sessions, building a cumulative knowledge base of what has been discovered about a design system. This is the cross-skill memory layer — it saves what was found, when, and by which skill, so future runs can compare, correlate, and avoid repeating work. Trigger when someone says: save these findings, remember this for later, compare with last run, what did we find before, load previous findings, recall the last audit, session history, show me what changed, cross-reference with previous runs, or anything about persisting, recalling, or comparing findings over time. Do NOT trigger for generating a single standalone report — use the specific skill for that. Do NOT trigger for running a full diagnostic — use full-system-diagnostic for that.

Write a one-page stakeholder brief translating design system health or status into business language. Trigger when someone says: stakeholder update, exec brief, leadership summary, status report for leadership, system status for non-designers, write a brief for the business, or anything about communicating design system status to an audience that does not have a design systems background.

Benchmark a design system against industry standards and comparable public systems, producing a qualitative comparison across dimensions with specific, named reference points. Goes beyond an internal health assessment to answer 'how does our system compare to what good looks like out there?' Trigger when someone says: benchmark our system, how do we compare, industry comparison, rate our system against others, where do we stand, compare us to Material Design, how mature is our system, are we behind or ahead, competitive assessment of our design system, or anything about comparing a design system's maturity or quality against external benchmarks. Do NOT trigger for an internal health check without external comparison — use system-health for that. Do NOT trigger for auditing a specific dimension — use the specific audit skill for that.

Run an overall health assessment across a design system, producing a findings-based summary across seven dimensions. This produces a holistic, cross-cutting health assessment, NOT a deep dive into a single dimension like components or tokens. Trigger when someone says: how healthy is my design system, overall system assessment, system health check, rate my system, design system audit, give me the big picture on my system, or anything asking for a holistic view of system quality rather than a focused audit of one area. Do NOT trigger for a deep component library audit — use component-audit for that.

Write a design system investment pitch with a business case and ROI framing. Trigger when someone says: pitch the design system, make the case for the system, sell this to leadership, justify the investment, business case for design systems, why should we invest in a design system, or anything about building an argument for design system investment or continuation.

Audit theme coverage and consistency across a design system's semantic and component token tiers. Triggers: audit my themes, check theme coverage, are all tokens defined across themes, dark mode audit, brand variant check, do themes have parity, theme consistency check, light/dark token coverage, or anything about whether themes are complete and internally consistent. Use this when launching a new theme, after a rebrand, adopting dark mode, or when token-audit reveals tier leakage that defeats theming.

Audit a design system's token definitions for naming violations, missing semantic tiers, and structural debt. This audits how tokens are defined and organised, NOT how they are consumed in code. Trigger when someone says: audit my tokens, token naming review, are my tokens consistent, token health check, review my token architecture, or anything involving token quality or structure. Do NOT trigger for checking whether code uses tokens correctly — use token-compliance for that.

Check a codebase or implementation for token compliance — finding hardcoded values, wrong-tier token references, and inconsistent token application in consuming code. This checks how tokens are used in code, NOT how the tokens themselves are defined or structured. Trigger when someone says: are we using tokens correctly, find hardcoded values, token compliance check, find raw values, token misuse, are there any hex values in the code, checking token usage, or anything about whether tokens are being used consistently and correctly. Do NOT trigger for auditing the token definitions themselves — use token-audit for that.

Write documentation for design tokens — covering semantic intent, usage context, and do/don't examples. Trigger when someone says: document these tokens, token reference, what does this token mean, token usage guide, write the token docs, token intent, or anything about creating human-readable documentation for design tokens.

Recommend which design system skills to run first based on a quick assessment of the system's state. Trigger when someone says: where should I start, what should I run first, triage my design system, which audit first, help me prioritise, I'm new to this system, first time using this plugin, or anything about deciding which skills or commands to use.

Write usage guidelines for a specific, named component — covering when to use it, when not to, edge cases, and anti-patterns for that one component. This documents HOW to use a component you have already chosen, NOT how to choose between components. Trigger when someone says: write usage guidelines for [component], do's and don'ts for [component], how should [component] be used, usage rules, write the guidelines for [component], or anything about creating prescriptive guidance for a single named component. Do NOT trigger for choosing between components — use component-decision-tree for that. Do NOT trigger for documenting multi-component patterns — use pattern-documentation for that.

Recommend the correct semver bump with reasoning and a generated changelog entry. Trigger when someone says: what version bump, is this a breaking change, semver recommendation, should this be major or minor, version this release, changelog entry, what kind of release is this, or anything about versioning a design system release.

Generate visual output — charts, dashboards, and trend graphs — from audit findings, session history, or system health data. Produces an interactive HTML dashboard or a set of SVG/Mermaid charts that make design system health visible at a glance. Trigger when someone says: visualise the findings, show me a chart, create a dashboard, graph the trends, make this visual, health dashboard, show me the data, I need charts for the stakeholder meeting, turn this into a visual report, or anything about producing visual representations of design system data. Do NOT trigger for producing a written stakeholder brief without visuals — use stakeholder-brief for that. Do NOT trigger for running an audit — run the audit skill first, then use visual-report to visualise the output.