Agent skills

Nine written workflows that let an AI agent build with this kit instead of guessing at it. They name the kit's 142 variant containers, its 33 semantic tokens and the traps in the Penpot API.

Two paths

The skills split down the middle, and you only ever load the half you need. Setup asks which one you are on.

Path A, in Penpot. The agent connects to the Penpot MCP server and assembles screens out of the kit's real component instances, bound to the kit's tokens. What comes out is still editable as components.

Path B, in code. The agent builds a live page from shadcn/ui plus the kit's tokens, without opening Penpot at all.

shadcn-kit-to-code is the bridge between them: it takes a design that already exists in Penpot and emits code by reading each instance's component identity rather than looking at a picture of it.

The skills

SkillWhat it does

shadcn-kit-setupConnect the Penpot MCP, or install shadcn/ui and the kit's tokens

shadcn-kit-selectDecide which component and which variant, used by both paths

shadcn-kit-designBuild in Penpot from real component instances, bound to tokens

shadcn-kit-to-codeConvert an existing Penpot design into code for your target

shadcn-kit-pageBuild a page in code from a description

shadcn-kit-import-tokensTokens and globals.css, in both directions

shadcn-kit-brandApply a brand by repointing tokens, not by editing components

shadcn-kit-auditSix sweeps: unbound colours, off-scale values, override drift, no active theme, orphans, kit drift

shadcn-kit-a11ySix sweeps against WCAG 2.2 AA: contrast, focus, target size, colour-only signalling

Installing

A skill is a plain folder: a SKILL.md and the references it reads. Nothing is compiled and there is nothing to configure. How a tool picks it up is the only thing that differs.

Claude Code

Unzip into the skills directory and the agent finds them by their descriptions. Every bundle is self-contained, so a skill installed on its own still resolves its own references.

unzip -q shadcn-kit-skills.zip && cp -R shadcn-kit-skills/shadcn-kit-* ~/.claude/skills/

Codex and Cursor

Neither has a skills directory. Both read an instructions file instead, so the folders go anywhere stable and a short routing table tells the agent when to open which one.

mkdir -p ~/design-skills && cp -R shadcn-kit-skills/shadcn-kit-* ~/design-skills/

Then paste the routing table from the package's install guide into:

Codex. ~/.codex/AGENTS.md for every project, or AGENTS.md at a repository root for one.

Cursor. The same AGENTS.md at the project root, so one paste covers both tools. A project rule at .cursor/rules/shadcn-kit.mdc works too - note the extension, a plain .md in that folder is ignored.

The routing table is not a degraded mode. For these two it is the mechanism, and the only real difference is that the agent chooses from a table rather than from each skill's own description.

Anything else

If the tool scans a folder for skills, drop them in - the format is the plain one and needs no conversion. If it does not, it reads some always-on instructions file, and the same routing table works there. Commit the folders into a shared repository and every teammate gets them from a checkout.

Code targets

A mapped target means every component family has a written translation. Four are fully mapped:

shadcn/ui for React, on Radix or Base UI

shadcn-vue for Vue 3

shadcn-svelte for Svelte 5

HTML and Tailwind with no framework

Material UI, Vuetify and Angular Material are documented as a second tier, with their losses named rather than papered over. Those libraries do not carry the same variant model, so the mapping says what survives and what does not before you commit.

Naming and routing

Skill names are brand-namespaced on purpose. Generic names collide the moment a second kit is installed, and then the router cannot tell them apart. Name the kit in your prompt and routing is reliable.

✓ "Build a login screen in Penpot with the shadcn kit"

✓ "Turn this Penpot screen into React using the shadcn kit"

○ "Build me a login screen" - a generic design skill takes it, correctly

That is not a defect to route around with greedier descriptions. It is how a shared skill namespace should behave.