plugin87/ux-ui-agent-skills: A Claude Instruction Layer for Token-Driven UI Work
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.
At a glance
- What is it?
- The repository ships a knowledge and instruction layer plus runnable skills that push Claude toward DTCG design tokens, WCAG 2.2 checks and framework-agnostic component specs. It is strongest as a constraint system for design-to-code work, and weakest wherever you need a library that actually renders.
- Who is it for?
- Adopt it if your team already writes UI inside Claude Code and wants token discipline and accessibility checks applied consistently across many components. Skip it if you need a rendering component library, a Figma plugin, or a CI product with a support contract, because this repository is an instruction and knowledge layer with scripts attached.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap This Fills: Consistency Between Design Intent and Generated Code
Ask an assistant for a button and you get a button. Ask it forty times across a codebase and you get forty buttons, each with its own padding scale, its own focus ring, and its own idea of what a disabled state looks like. The repository frames its purpose around exactly that drift: it describes itself as a kit of structured instructions, design tokens, runnable skills and 138 design systems that target any framework and any design system, with the stated goal of consistent, accessible, token-driven design outputs. The audience is narrow but real. It is for people who already drive UI work through Claude Code or a Claude-powered IDE and want the model constrained by a written specification rather than by whatever the prompt happened to imply. The README is explicit that there are no build tools, dependencies or runtime, calling it a pure instruction and knowledge layer for AI agents. That framing matters more than any feature list, because it defines both what the project can do and what it cannot.
Token Tiers, Atomic Design and the Adapter Protocol
The mechanism has three parts. First, tokens. The kit emits DTCG-format JSON covering color, typography, spacing, shadows, borders, breakpoints and motion, organised in a three-tier architecture the README names Primitive, then Semantic, then Component. That ordering is the load-bearing decision: a component never references a raw hex value, it references a semantic role that resolves back to a primitive. Second, components. Design work follows Atomic Design from atoms up to templates, and each component spec carries anatomy, variants, states, token mapping and accessibility notes. Third, code output. An Adapter Protocol is the abstraction that lets one component spec produce React with Tailwind, Next.js, SwiftUI, Vue, Svelte, Angular, Solid, Web Components via Lit, React Native, Flutter, Jetpack Compose, vanilla CSS or CSS-in-JS, and the README states an adapter can be generated on demand when the target is missing. Design-system interop uses a role-based crosswalk so a spec can map to or from Material 3, Apple HIG, Fluent, Carbon, shadcn/ui or Radix. The data flow is therefore one directional: tokens define roles, roles bind to component slots, adapters translate slots into framework syntax. Nothing in that chain executes at runtime.
Installing the Kit and Scaffolding a Product Repository
Two installation paths are documented. The recommended one is npx ux-ui-agent-skills init, which drops the full kit into the current folder. Selective installation uses npx ux-ui-agent-skills add tokens taste design-systems, and npx ux-ui-agent-skills list enumerates the available areas. Two flags are documented: --force overwrites existing files and --dry previews without changing anything. The alternative is a clone followed by copying the directory into your project. Activation is automatic: the README states that opening the project in Claude Code loads CLAUDE.md, which activates the agent persona with access to the token, component, taste and design-system files plus the runnable skills. For a new product there is a second layer. templates/product-design/ is a starter you copy, containing CLAUDE.md as the session brief, a gitignored CLAUDE.local.md for personal preferences, .mcp.json for Figma and Notion connections with env expansion and no secrets, a .claude/ directory holding rules for components, tokens and accessibility that load only when relevant, plus skills, commands and settings.json, and finally design-tokens.json as the source of truth for color, type and spacing in light and dark variants. The scaffold command is /scaffold-project ../your-product, run from a clone of the repository, and the README shows it copying the template and then installing engine areas next to it with npx ux-ui-agent-skills add.
The Runnable Checks Are Where the Project Stops Being Just Prose
Most prompt kits are markdown and hope. This one ships scripts, and that is the part worth examining. The README lists 17 invocable skills, each declaring invocation: user or invocation: model, alongside 4 slash commands. The scripts named include token and contrast validators, real-render and state-aware WCAG gates, axe-core accessibility checks, focus-trap, RTL, target size, keyboard, reduced motion, overflow, token-by-intent, taste and slop audits, and a token build. The distinction between the two invocation modes is the practical one: a skill marked user runs when you call it, a skill marked model can be selected by Claude itself during a task. The repository also advertises 37 objective gates, which is a claim about how many pass or fail conditions the checks encode, not a claim about your codebase. Accessibility is evaluated against WCAG 2.2 at AA and AAA with findings prioritised as P0, P1 and P2. Design review is separate: six scoring dimensions plus Nielsen's ten heuristics in a structured findings table. Whether those gates are strict enough for your product is something only running them on your own components will tell you, and the README does not publish their failure thresholds.
Where the Instruction-Only Design Hurts
The same property that makes the kit easy to adopt limits it. There is no runtime and no rendering layer, so nothing here can tell you what a component looks like. The real-render WCAG gate implies a rendered page exists, but the kit does not produce one; you supply the markup and the check inspects it. That means the quality of every audit is bounded by how faithfully the generated code was actually built into your application. A second limitation is the adapter surface. Sixteen framework adapters are advertised, and the README says a new adapter can be generated on demand. Generated adapters are unverified by definition. If your stack is unusual, you are relying on the model to invent a correct translation, and the repository offers no conformance suite for that case. A third issue is scope creep in the other direction: the kit covers prototyping fidelity ladders, user journey mapping, usability testing scripts, UX writing voice and tone, error and empty-state formulas, and motion tokens with a reduced-motion strategy. A team that only wants token generation and component specs is installing a large body of opinionated guidance to get it. Finally, the licence is genuinely unclear from the material. The README carries an MIT badge, but the repository metadata supplied lists the licence as unknown. Treat that as unresolved until you read the LICENSE file.
How It Differs From shadcn/ui, Radix and Storybook
The obvious comparison is shadcn/ui, and the difference is categorical rather than incremental. shadcn/ui gives you source files you copy into your project: real React components that render, with Radix primitives underneath handling focus management and ARIA behaviour. You can run it, screenshot it, and ship it. This repository gives you instructions and validators that influence what an assistant writes. It can target shadcn/ui as a design system through its crosswalk, but it does not replace it. The same applies to Radix, which supplies accessible primitives in code, and to Storybook, which renders and documents components in isolation. If your problem is that you need components today, the kit does not solve it; if your problem is that your team generates components inconsistently and skips accessibility details, it addresses that directly. The honest framing is that this is complementary tooling. It sits upstream of a component library and tries to make the code that lands in that library conform to a token contract.
Maintenance Cost and What the Release Cadence Suggests
Three releases appear in the supplied material: v2.5.1 and v2.5.0 in late August 2026, one day apart, and v2.4.0 roughly two months earlier in June 2026. The current version is v2.5.1, and the last push timestamp matches the v2.5.1 release date. That pattern suggests active but bursty maintenance, with patch releases following minor ones quickly, which is normal for a project whose surface is mostly content. Upgrade cost is low in the mechanical sense, since npx ux-ui-agent-skills init with --force overwrites files and --dry lets you preview the diff first. The real cost is content drift: if you edited the shipped token files or component specs to match your brand, a forced reinstall discards those edits. The scaffolded product template mitigates this by separating your design-tokens.json and your .claude/rules from the engine areas, which is the right split and worth preserving. On licensing, the README links an MIT badge to the licence section, but the repository metadata does not confirm a licence identifier. If you plan to redistribute the 138 bundled design systems, resolve that discrepancy first. This is not legal advice; read the LICENSE file and decide with whoever handles compliance.
Editorial conclusion
Adopt it if your team already writes UI inside Claude Code and wants token discipline and accessibility checks applied consistently across many components. Skip it if you need a rendering component library, a Figma plugin, or a CI product with a support contract, because this repository is an instruction and knowledge layer with scripts attached. Verify three things before committing: the actual contents of the LICENSE file, since the README badge and the repository metadata disagree; which of the 17 skills declare invocation: user versus invocation: model, because that decides what runs without you asking; and whether the framework adapter you need exists in the adapter set or has to be written.
Community notes