UI Design & Frontend Skills

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. Here 'coverage' means adoption coverage (how much of the system teams actually use). Do NOT trigger for documentation coverage or doc staleness — use docs-coverage for whether the documentation surface keeps pace with the components.

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.

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.

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.

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.

Audit whether a design system's documentation surface keeps pace with its component library — coverage gaps (components with no docs), staleness (docs that predate the component's last code change), and orphaned docs. Works with zero integration from the codebase and a Storybook build; Zeroheight, Supernova, and custom docs sites are optional layers. Trigger when someone says: docs coverage, documentation audit, are our docs up to date, which components are undocumented, is our documentation keeping pace, stale docs check, documentation health, Storybook coverage, or anything about whether the documentation surface matches the components. Do NOT trigger for WRITING documentation — use usage-guidelines, pattern-documentation, token-documentation, or ai-component-description for that. Do NOT trigger for general system health (use system-health) or for documentation usage/analytics (use adoption-report).

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.

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.