The Claude Code Skills I Use to Build Frontends

I have 194 skills installed across the user directory, this repo, and plugins. That number is not a brag, it is the problem. Most of them I installed once, used never, and could not describe today.

Six survive contact with real frontend work. This is what each one changed, where two of them overlap enough that you only need one, and the category that quietly does nothing.

Every "best Claude Code skills" list I have read is a list of things the author installed. This one is a list of things that changed an output I can point at, which is a shorter list and a more useful one.

What separates a skill that works from one that does not

Worth stating the rubric first, because it predicts the list better than any individual review.

Skills that carry reference material win. Skills that carry opinions lose. An agent already has opinions about frontend code. What it does not have is your exact GSAP version's API surface, or a named list of the twelve things that make a card look cheap. The useful ones are lookup tables.

The description is the routing interface. An agent decides whether to load a skill by reading its description, never its body. Half the skills I abandoned were good inside and unroutable outside, and the difference is visible in two lines of frontmatter:

---
name: motion-helper
description: Helps with animations and making things look nice.
---

Nothing in that routes. "Animations" is a topic, not a trigger, and the agent has no way to tell whether this applies to the task in front of it. Compare the one that ships with gsap-scrolltrigger:

---
name: gsap-scrolltrigger
description: Official GSAP skill for ScrollTrigger. Use when building or
  recommending scroll-based animation, parallax, pinned sections, or
  scrub-linked timelines.
---

Same subject, but written as a condition. When you find yourself wondering why a skill never loads, the body is almost never the problem.

Length is a cost, and it should buy something. A skill's body enters the context window the moment it is loaded. A 1,200-line skill needs to be 1,200 lines good. Most are not, which is what progressive disclosure exists to solve.

A skill that only says "do a good job" is a prompt in a trench coat. If you can delete the file and lose nothing, delete the file.

The six that stayed

1. The GSAP suite, and only three of the eight

The official GSAP skills come as eight separate folders: core, ScrollTrigger, timeline, React, plugins, performance, frameworks, utils. Installing all eight is the obvious move and the wrong one.

Three carry their weight. gsap-core (254 lines) covers gsap.to, easing, stagger, and gsap.matchMedia, which is the correct hook for prefers-reduced-motion. gsap-scrolltrigger (296 lines) covers scrub, pinning, and trigger boundaries, which is where hand-written scroll code goes wrong. gsap-timeline covers sequencing.

The other five I keep uninstalled. Not because they are bad, but because their content is either rarely needed or already implied by the three above, and every installed skill is one more description competing for a routing decision.

What actually changed: the agent stopped inventing plugin APIs. Before, scroll animations came back with confidently wrong option names that failed at runtime. After, they came back correct on the first attempt, because the exact API surface was in front of the model instead of being recalled from training data.

Skip it if: you are not animating. This is a reference manual, not a taste skill, and it does nothing for a static page.

2. design-taste-frontend: the one with the biggest effect

At 1,206 lines this is the longest skill I run, and it is the one I would keep if I could keep only one. Its own description calls it an "anti-slop frontend skill," which is exactly right: it is a catalogue of the specific decisions that make an interface look machine-made, and what to do instead.

The mechanism is not inspiration. It is a list of named failure modes and their fixes: default type stacks, one radius applied everywhere, uniform spacing that groups nothing, color spent on decoration rather than meaning.

Here is the difference on a component I asked for twice, once with the design skills loaded and once without, with identical wording both times:

Same content, same component, same request. What moved was the type scale doing the ranking, spacing being used to group, and the color budget being spent once instead of everywhere.

Skip it if: you are working inside an established design system. If the tokens and components already exist, this skill will argue with them, and the design system should win.

3. ui-ux-pro-max: the widest of the Claude design skills

660 lines covering, by its own count, 50+ styles, 161 color palettes, 57 font pairings, 161 product types, 99 UX guidelines, and 25 chart types.

That inventory is the point. It is most useful at the very start, when the answer to "what should this look like" is genuinely open, and you want a named direction plus a font pairing that someone has already checked. It is least useful mid-build, where its breadth makes it slower than just deciding.

Where it overlaps: it and design-taste-frontend cover adjacent ground, and running both on the same task produces two answers you then have to reconcile. I use this one to pick a direction and the other one to execute it. If you want a single skill, take design-taste-frontend.

4. responsive-design-audit: the only one that finds bugs

54 lines, and the shortest skill on this list does the most concrete work. It walks a page across breakpoints hunting horizontal overflow, tap-target sizes, and text that clips or wraps badly.

This is the only skill here that finds defects rather than improving output. It caught a pill label wrapping mid-word at 390px that every "does the flow work" check had passed, because the flow did work, it just looked broken.

What makes it work: it exercises data-dependent branches. Layout bugs hide in the states you did not seed, so an audit that only loads the empty state finds nothing.

Skip it if: never, honestly. It is 54 lines and it pays for itself the first time it runs.

5. review-animations: earns its place by being harsh

112 lines, and the description carries the whole design: "Default to flagging; approval is earned."

That inversion is why it works. Most review skills are agreeable, and an agreeable reviewer is worse than none, because it produces a confident approval that feels like a gate. This one starts from the assumption that the motion is wrong and makes you argue it into approval. Typical catches are durations too long to feel responsive, easing that is linear where it should not be, and animations that ignore prefers-reduced-motion.

6. avoid-ai-writing: for the copy, not the code

683 lines auditing prose for AI writing patterns. It belongs on a frontend list because interfaces contain copy, and machine-written microcopy is as recognizable as machine-made layout. Empty state text, button labels, and error messages are where it shows.

Skip it if: you have a content designer. This is a substitute for taste, not an upgrade over it.

Two that did not make it

Being honest about the misses is more useful than another six-item list of things that are all great.

high-end-visual-design (98 lines) promises to "design like a high-end agency" and defines fonts, spacing, shadows, and card structures that make a site feel expensive. It is not wrong. It is redundant: everything it does, design-taste-frontend does at more depth, and running both means two skills competing to answer one question. I keep it uninstalled.

Aesthetic preset skills in general are the category that quietly does nothing. Minimalist, brutalist, and similar style skills produce a recognizable look on the first try and then fight you on every subsequent change, because the preset is a destination rather than a set of tools. A named direction from a lookup table plus a taste skill that explains its reasoning beats a preset you cannot argue with.

The pattern underneath

Line up the six that stayed and the ones that did not, and the split is clean.

The survivors carry material the model does not already have: an exact API surface, a named list of failure modes, a breakpoint checklist, an inventory of font pairings. The ones I dropped carry judgment the model already has, phrased more confidently.

So the test before installing anything is one question. What does this file know that the model does not? If the answer is "nothing, it just asks nicely," the file is a prompt with extra steps.

When a skill is the wrong shape

Claude skills are public instructions, and that is their design, not a limitation. A skill is copied, read, edited, and version-controlled, which is exactly what you want for a GSAP reference or a breakpoint checklist. Nobody loses anything by gsap-scrolltrigger being readable.

The shape breaks when the expertise is the thing being sold. A design studio's actual process. An audit method a consultant charges for. A conversion playbook built from client data nobody else has. Ship those as a skill and you have given them away, because a skill lands on the reader's disk in full. That threat model is worth reading in agentic AI skill security.

A sealed Expert is the same idea with the file kept back. It holds many skills, documents, and tools at once, it runs server-side, and the caller receives the answer rather than the instructions. Your agent calls it as one more tool: over MCP for any client that speaks it, or via askpert add <expert-id>, which writes adapters for 72 coding agents and harnesses. From the agent's point of view there is no difference between calling a local skill and calling a rented one. From the author's, there is all the difference.

That is the trade in one line: a skill scales knowledge you are happy to publish, and a sealed Expert scales knowledge you are not. Most of the six above should stay skills. If you have a playbook that took years to build, it should not.

Browse the Experts other agents are calling.

Claude Code skills FAQ

Package the method you cannot publish

If one of your skills is the thing you would rather not hand out, it is in the wrong container. Put the knowledge, prompts, documents, and tools into a protected Expert instead, and other people's agents call it over MCP or REST while the files stay on the server.

Create an Expert and see what it is worth to somebody else's build.