# ux-ui-agent-skills: A Claude Skill Kit for Token-Driven UI Work

> The kit installs a design-architect persona into Claude Code through CLAUDE.md, DTCG tokens and 17 runnable skills. It is an instruction layer, not a component library, and that distinction decides who gets value from it.

**plugin87/ux-ui-agent-skills** — Turn Claude into a Senior Design Architect — DTCG design tokens, 42 components, WCAG 2.2 accessibility, any-framework code, 138 design systems, and runnable skills.

- Repository: https://github.com/plugin87/ux-ui-agent-skills
- Stars: 1,511 · Forks: 160
- Language: JavaScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/plugin87-ux-ui-agent-skills

## What ux-ui-agent-skills actually solves

Ask a general coding assistant for a button and you get a button. Ask it for a button that matches your spacing scale, passes contrast at AA, handles focus-visible and reduced motion, and maps to your semantic color roles, and the request collapses into a long prompt that you rewrite every session. This project's answer is to stop prompting and start installing: a knowledge layer that Claude Code reads automatically, so the constraints are present before you type anything.

The target user is a frontend or design-systems engineer working inside Claude Code who already has opinions about tokens and accessibility. The README positions the kit as a set of "structured instructions, design tokens, runnable skills, and 138 brand-grade design systems" that target any framework and any design system. That word "any" is doing real work in the pitch and deserves scrutiny later, because a crosswalk between Material 3 and Apple HIG is a mapping table, not a compiler.

It is not a component library. The repository has a components/ directory, but what lives there per the README is component design specification: anatomy, variants, states, token mapping, accessibility notes. Nothing renders until a framework adapter turns a spec into code, and that code is generated into your project, not imported from this one.

## The three-tier token model and the adapter protocol

The mechanism that holds the whole kit together is the token architecture. The README describes DTCG-format JSON split into three tiers: Primitive, then Semantic, then Component. A primitive is a raw value, a semantic token names an intent, and a component token binds that intent to one part of one component. The practical consequence is that a rebrand touches the semantic layer and leaves component specs alone, which is the same argument every design-systems talk makes, but here it is enforced by validators rather than by convention.

On top of that sits the Adapter Protocol, which the README says targets React with Tailwind, Next.js, SwiftUI, Vue, Svelte, Angular, Solid, Web Components and Lit, React Native, Flutter, Jetpack Compose, vanilla CSS and CSS-in-JS, or generates a new adapter on demand. Sixteen framework adapters are listed in the badges. The data flow is one direction: a component spec plus a resolved token set goes in, framework-specific code comes out. There is no round trip, so generated code that you hand-edit will not be re-imported into the spec.

Design-system interop works the same way, through what the README calls a role-based crosswalk to Material 3, Apple HIG, Fluent, Carbon, shadcn/ui and Radix. A crosswalk maps role names, not component internals, so expect a Fluent button to arrive as your button with Fluent's role assignments, not as a Fluent component.

## Installing the kit and running a first audit

The README gives two install paths. The recommended one uses npx and drops the kit into the current folder without a clone. The second clones the repository and copies it. Both are pure file placement: the README states there are no build tools, dependencies or runtime required.

```bash
npx ux-ui-agent-skills init
```

That copies the full kit into the working directory. The README documents two flags: --force to overwrite existing files and --dry to preview without changing anything. If you only want part of the kit, add named areas instead, and list the available ones first.

```bash
npx ux-ui-agent-skills list
npx ux-ui-agent-skills add tokens taste design-systems
```

The output of list is the set of installable areas; the add command takes those names as positional arguments. After either path, the README says to open the project in Claude Code, where CLAUDE.md loads automatically and activates the persona with access to the tokens, components, taste and design-system files plus the runnable skills.

For a first real use, start with the token validators rather than a component prompt. The repository ships Python scripts, and package.json wires them into the test script.

```bash
python3 scripts/validate_tokens.py
python3 scripts/validate_contrast.py
```

The first checks token structure, the second checks contrast. Run them against your own design-tokens.json before you ask Claude to design anything, because a failing palette will poison every component the agent generates downstream.

## Where the gates stop and you have to look

The kit leans hard on objective gates. The README counts 37 of them, and package.json exposes scripts for target size, keyboard, reduced motion, hardcoded values, theme references, intent linting and a slop audit. That is a genuine differentiator: most prompt packs ship prose, and this one ships exit codes.

Read the gate list carefully, though, and you see what is not covered. There is a script for target size and one for keyboard, but no automated check for screen-reader announcement order, live-region politeness, or whether an aria-label actually describes the control. Those remain judgement calls, and the README's accessibility section describes WCAG 2.2 AA to AAA evaluation with P0/P1/P2 prioritization, which is a human-readable findings table, not a pass or fail. Treat the scripts as a floor.

The bigger limitation is the framework claim. The adapter list is long, but an adapter is only as good as the spec it reads, and the README does not describe a conformance test suite that proves a SwiftUI adapter produces idiomatic SwiftUI. If you are on Flutter or Jetpack Compose, verify output quality on one real screen before you restructure a design system around this.

One more: the README's badge row shows version 2.5.1 while package.json in the repository carries version 2.10.0. That mismatch is worth resolving before you pin a version in CI.

## How it differs from shadcn/ui and Storybook

The closest comparison people will reach for is shadcn/ui, and the difference is categorical. shadcn/ui gives you component source you copy into your project and then own; it renders, it has runtime behaviour, and its theming is CSS variables. ux-ui-agent-skills gives you instructions, token files and specs that a model reads. It has no rendered output of its own. If your problem is "I need a dialog today", shadcn/ui solves it and this kit does not.

Against Storybook the split is similar. Storybook documents and isolates components you already have, and its value grows with a component inventory. This kit is upstream of that: it helps decide what the component should be, which tokens it consumes, and which states it needs, before any story exists. A team running both would use this kit to draft the spec and Storybook to hold the result, though nothing in the README describes an integration between them.

The honest framing is that this is closer to a style guide plus a linter than to a UI dependency. Its output is your project's code, generated once, and the kit's ongoing job is keeping the agent consistent while you generate more.

## Maintenance, licence and what an upgrade costs

The last push to the default branch was on 2026-08-26, and the most recent release, v2.5.1, is dated the same day. The release before it, v2.5.0, landed on 2026-08-25, and v2.4.0 on 2026-06-22. That is a recent cadence with a long gap in the middle of the year, so the project is moving but not on a schedule you can plan a freeze around.

Upgrade cost is low in the mechanical sense and higher in the semantic one. Because the kit is copied files, upgrading means re-running the installer with --force, which the README documents as overwriting existing files. Anything you edited in the copied tokens, components or taste directories is at risk. The README does not document a rollback path or an upgrade command that preserves local edits, so keep your own design-tokens.json under version control separately.

Licensing is where the material is inconsistent. The README carries an MIT badge and a LICENSE file exists at the repository root, but the repository metadata supplied for this project lists the licence as unknown. Do not treat the badge as authoritative. Open LICENSE and read it, and if you need MIT terms in writing for a commercial distribution, get that confirmed rather than inferred from a shield image.

## Conclusion

Adopt it if your team already runs Claude Code and wants token-driven, accessibility-checked UI output with a repeatable gate script. Skip it if you need a shipped component library, a Figma plugin or a runtime dependency, because the kit produces instructions and specs rather than rendering anything itself. Before committing, read LICENSE and confirm the MIT badge in the README matches the file, then run npx ux-ui-agent-skills list to see which areas exist, and run the token and contrast validators on your own design-tokens.json to check that your palette survives the gates.

## FAQ

### What is ux-ui-agent-skills and what does it do for Claude?

It is an instruction and knowledge layer that turns Claude into a design-architect persona inside Claude Code, with DTCG design tokens, component design specs, accessibility auditing against WCAG 2.2 and 138 design systems. The README states there are no build tools, dependencies or runtime required.

### How do I install ux-ui-agent-skills?

The README recommends npx ux-ui-agent-skills init to drop the full kit into the current folder, or npx ux-ui-agent-skills add with named areas for a partial install. A git clone and copy is documented as the alternative. Both flags --force and --dry are listed.

### Do I need any UI/UX skills to use ux-ui-agent-skills?

The kit supplies the design knowledge the agent applies, but the README's usage examples assume you can judge the output: reviewing a login page against WCAG 2.2 and Nielsen's heuristics, auditing a form, or specing motion with a reduced-motion fallback. The runnable validators in scripts/ give you objective checks regardless of your design background.

### Which frameworks can ux-ui-agent-skills generate code for?

The README lists React with Tailwind, Next.js, SwiftUI, Vue, Svelte, Angular, Solid, Web Components and Lit, React Native, Flutter, Jetpack Compose, vanilla CSS and CSS-in-JS, with 16 framework adapters and the option to generate a new adapter on demand.

### Is ux-ui-agent-skills a component library like shadcn/ui?

No. The components directory holds design specifications such as anatomy, variants, states and token mapping. Rendering happens only when a framework adapter generates code into your project. shadcn/ui ships component source that renders; this kit ships instructions a model reads.

## Sources

- [Issues](https://github.com/plugin87/ux-ui-agent-skills/issues)
- [plugin87/ux-ui-agent-skills on GitHub](https://github.com/plugin87/ux-ui-agent-skills)
- [README](https://github.com/plugin87/ux-ui-agent-skills/blob/main/README.md)
- [Releases](https://github.com/plugin87/ux-ui-agent-skills/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/plugin87-ux-ui-agent-skills
