What 117 UI skills actually change: notes from 1,770 generated pages

Agent skills (a SKILL.md file your coding agent reads before it works) have become the default way to give Claude Code, Cursor or Codex a sense of taste. There are now hundreds of front-end "design" skills, and most of them describe themselves the same way: distinctive, intentional, not generic.

I wanted to know what they actually do, so I built SkillArena and ran a controlled comparison.

The setup

• 5 fixed briefs, sent word for word: a SaaS landing page, an analytics dashboard, a mobile app screen, a sign-up form, and SkillArena's own home page.
• One model (Claude Opus 5.5) at default settings.
• 117 skills from 25 authors, plus a control row with no skill. Each row puts one skill's SKILL.md (and any reference files it points to) into the same short system prompt. Nothing else changes.
• 3 runs for every skill × brief, all published. That's 1,770 pages, every one screenshotted and openable in a sandbox.
• Each skill is pinned to a git commit, so the results match a specific version you can install.

There is no score and no leaderboard. I don't trust any automated design score enough to publish one. What I can do is count things.

1. Skills change the look far more than the words

The landing page brief describes a shared calendar for small teams whose selling point is that it "automatically finds a time when everyone is free." It doesn't suggest a headline.

317 of the 354 landing pages open with "Stop asking…": "Stop asking 'when works for everyone?'", "Stop asking 'when are you free?'", and so on. The no-skill control did it in all 3 runs. So did 94 of the 117 skills, including a skill written specifically to improve UX copy.

Only two skills avoided it in every run:

• Elaya's landing-page-design: "Find a time everyone is free without the reply all thread."
• Addy Osmani's SEO skill: "The shared calendar that finds a time everyone is free." All three runs put the product's actual keyword in the H1, which is exactly what an SEO skill should do.

The pages themselves look very different from each other, with different layouts, type and colour. But underneath, the model mostly says the same thing. If you want different copy, a visual design skill probably won't give it to you. A skill that changes what the model is trying to achieve (rank for a keyword, follow a copy framework) might.

The home page brief shows the same pattern. 205 of 354 pages used the exact headline "Same brief. Different skill.", and only 15 skills never did. Brutalist went with "ONE BRIEF. EVERY SKILL. NO GUESSING."

2. "Does a skill make the model write more?" depends on the brief

I expected skills to make pages bigger across the board: more instructions, more effort, more output. That's true for some briefs and false for others.

Here are the average output tokens per page, no skill vs the median skill:

On small, open-ended briefs (a phone screen, a form), the model on its own does the minimum, and almost any skill pushes it to build more. On the dashboard, the model already writes a lot on its own, and most skills (82 of 117) make it write less: tighter layouts, fewer charts, less filler.

Across all five briefs, 21 of 117 skills averaged fewer output tokens than no skill at all. The smallest was Subtractive Design (5.4k per page), which is at least honest about its name. The largest was Emil Kowalski's Prototype skill at 36.2k, nearly 3× the control. On the mobile brief alone it was over 7×.

None of this says which pages are better. A bigger page isn't a better page. But size is a practical signal: it tells you how much a skill changes the cost and latency of every generation, and it tells you the skill is doing something.

3. Usually consistent, occasionally wild

With three runs per cell, you can see how stable a skill is. For output size, most are fairly stable: in about 9 of 10 skill × brief cells, the largest run was less than 1.5× the smallest.

The exceptions are big. The Soft skill on the home page brief produced 17k, 23k and 44k tokens across three runs. The screenshots look like three different skills. If you had judged that skill from the 17k run alone, you'd have the wrong idea about it.

Run 1 of 3 above. All three runs side by side.

That's why SkillArena shows all three runs side by side instead of a best pick. Cherry-picking is the default in skill READMEs and on social media, and it's easy to do by accident.

What I'd take from this

• Look before you install. Two skills with near-identical descriptions can produce very different pages, and a skill described as "distinctive" can produce something close to the default.
• Test on your kind of page. A skill that transforms a form or a phone screen may barely touch a dashboard, and the reverse.
• Don't expect a design skill to fix copy. If the words matter, use a skill (or a prompt) that changes what the page is trying to say.
• Look at more than one run. Most skills are consistent, but the ones that aren't can fool you with a single screenshot.

Caveats

• Skills are always fully loaded. In real Claude Code, the agent sees a skill's description first and decides whether to load it. Here, every skill is always fully loaded. That isolates what the instructions do, not how often they'd be used.
• One model. Other models will likely behave differently.
• Single-file HTML. All five briefs ask for self-contained HTML pages, which suits some skills better than others. Skills written for a specific stack, like Vue or a component library, are at a disadvantage, and their pages say so.
• Token counts aren't quality. They're just the most objective thing I can count.

Everything is public:

• The site: skillarena.dev.
• Every run, token count and list-price cost: /results.json.
• The code (MIT): github.com/xyunsh/skillarena.

If you maintain a skill and something about how it's described or installed is wrong, or you'd like yours added, open an issue and I'll fix it.