We Built the Same Landing Page With and Without a Skill

The Skill Bench, part 1 of 4. Same model, same prompt, one skill installed or not. This entry: a landing page. Also in the series: a Telegram bot, debugging a snake game, and auditing a Google zx script.

Every skill review on this site ends with the same unresolved question: does this skill make Claude do better work, or does it just make Claude do more work? Those aren’t the same thing, and most testing setups can’t tell them apart because the runs aren’t controlled tightly enough to isolate the one variable that matters.

So we ran an experiment. Two runs, same model, same brief, down to the punctuation. The only difference between them is one instruction: “read and follow this installed skill.” Run one, the model builds unaided. Run two, we point it at the actual frontend-design skill, the one that sits at 9.6 out of 10 in our catalog, and let it read the real SKILL.md before touching any code. Then we diff the two landing pages line by line and count the tokens each run cost.

This is the first of four such comparisons. We picked a landing page to start because visual design is the domain where “better” is easiest to argue about and hardest to fake. A gradient-heavy hero either looks like every other AI-built page or it doesn’t, and you don’t need a benchmark to see which.

The setup

The brief was the same for both runs, a single-file landing page for “Nimbus,” a fictional weather API, written to a Stripe-calibre standard: hero section, three feature blocks, a pricing table with Free, $29, and $199 tiers, a code example block, and a footer. No frameworks, no build step, one HTML file with embedded CSS.

Run one got that brief and nothing else. Run two got the identical brief plus a pointer to the installed frontend-design skill, which the model then read in full before starting.

One important caveat, stated plainly rather than buried: this is N=1. One run per arm, one model, one brief. We’re not claiming these numbers are statistically stable across a hundred trials, and if you rerun this yourself you’ll get different specific numbers. What we are claiming is narrower and, we think, more useful: this is what happened, in detail, on a real run, with real telemetry, and it’s a pattern we’ve seen often enough in less controlled testing to trust the shape of it even before we run rounds two and three.

What the baseline built

Left to its own devices, Claude produced a page most people who have looked at a lot of AI output would recognize immediately. 890 lines, a light color scheme built around paper and amber tones, and it’s worth being fair here: the code was clean, the copy was reasonable, the layout worked, nothing was broken.

The tells were all in the details. Eleven separate gradients across the page, in the hero background, in button states, in card borders, in places where a gradient added visual noise rather than doing a job. Two headlines used background-clip: text to paint the text itself in a gradient, the single most recognizable AI-design signature there is at this point. Stat numbers floated in their own cards above the fold, detached from any layout logic, the kind of element that looks like it was added because a template somewhere has one, not because this particular page needed it.

None of this is incompetent. It’s the output of a model that’s good at web design in general and has no specific point of view about this brand in particular, so it reaches for the same moves that show up whenever the same question gets asked without more constraint. A 63,329-token run bought a shippable page. It didn’t buy a page anyone would remember, and it’s the same page we’d expect from most of the skills in our best design skills roundup if you strip the design skill back out.

What the skill arm built differently

The skill-guided run read the actual anthropics/skills frontend-design SKILL.md before writing anything, and the resulting page reads like it came from a different design brief entirely. Dark navy background (--bg: #0B1119) paired with a brass accent (--brass: #D2A25C), a combination that shows up nowhere in the baseline’s search space and reads as a deliberate choice rather than a default. 985 lines, four gradients instead of eleven, and zero instances of gradient-text. Not fewer, zero. The type system was disciplined in a way the baseline’s wasn’t: consistent scale, consistent weight logic, headings that look chosen rather than sized to fit.

Nothing about this page screams “premium” the way a stock photo of a handshake screams “corporate.” It’s quieter than that. The palette is unusual enough that it doesn’t read as a template, and the restraint on gradients means the ones that remain actually carry weight instead of decorating everything they touch. If you handed both pages to a client and asked which one a design-conscious founder would ship, this isn’t a close call.

The numbers

	Baseline (no skill)	Skill arm (frontend-design)	Delta
Tokens used	63,329	125,165	+98%
Tool calls	6	57	+51
Output length	890 lines	985 lines	+95 lines
Gradients	11	4	-7
Gradient-text instances	2	0	-2
Palette	Light, paper + amber	Dark navy + brass	—

The token number is the headline and it’s not subtle: the skill run cost almost twice as much. That’s not a rounding error you can attribute to noise, and it’s the number every other claim in this piece has to be read against.

Why the skill costs more

The token gap isn’t really about the skill’s file size. SKILL.md files are typically a few thousand tokens, not enough on their own to double a 63k-token run. What actually happened is visible in the tool-call count: 6 versus 57. The baseline run wrote the page and was done. The skill run read the skill, then iterated against it, checking its own output against a checklist the skill lays out, adjusting spacing, revisiting color choices, second-guessing a layout decision it had already made once.

That’s the mechanism, and it’s worth naming because it means the token cost isn’t “reading a longer document.” It’s “doing the work more than once.” A skill that describes what good design looks like turns a single-pass generation task into something closer to a self-review loop, and self-review loops are expensive in tokens by nature, whether a human or a model is running them.

When +98% tokens is a bargain, and when it isn’t

If the deliverable is the design, this is not a hard call. A landing page that a client will look at, a portfolio piece, anything where “does this look like it was made by someone with taste” is part of the job description: the token cost here is closer to a rounding error than a budget line. Nobody debates paying a designer for a second draft. Paying a model in tokens for the equivalent iteration is the same trade at a much lower price, even at double the baseline cost.

If the deliverable is an internal tool, a prototype nobody outside the team will see, or a page that exists to prove an API endpoint works rather than to represent a brand, skip it. The baseline’s paper-and-amber page with its stray gradients does the job. Nobody evaluating an internal admin panel is going to notice that the headline used background-clip: text, and paying double the tokens to fix a flaw nobody will see isn’t a quality purchase, it’s just a bigger bill.

The decision point isn’t the skill’s quality, which is real. It’s whether anyone is going to look at the result closely enough to care.

How to reproduce this yourself

You don’t need our exact brief to run this comparison on your own work. The setup is simple enough to redo in an afternoon.

Write a brief with concrete constraints: a product name, a specific set of sections, a specific pricing structure, “no frameworks” if that matters to you. Vague briefs produce vague deltas, because there’s less for a design skill to push against.

Run it once with a clean model and no skills installed. Save the output and note the token count from your harness telemetry, not an estimate.

Install frontend-design (or whatever design skill you’re evaluating), restart your session so the skill’s description is freshly loaded, and run the identical brief again, changed by nothing except a line telling the model to read and follow the skill.

Diff the two outputs for the specific tells we found here: gradient count, use of background-clip: text, whether the palette looks chosen or default, whether the type scale is consistent. Read our testing protocol for the fuller version of this process, including the trigger battery we run before any output comparison.

Compare token counts last, after you’ve formed an opinion on the output. If you look at the bill first, it colors how generous you are with the visual comparison, and that ordering matters more than it sounds like it should.

FAQ

Does the frontend-design skill always double token usage? Not necessarily, and we’re not claiming a fixed multiplier. This run showed +98% on one brief with one model. The mechanism behind the increase, more tool calls because the model checks its output against the skill’s own guidance, should generalize, but the exact percentage will move with brief complexity and how much back-and-forth the model decides it needs.

Is one run per arm enough to trust these numbers? Enough to trust the pattern, not enough to trust the precise percentage. We’re calling this N=1 deliberately so nobody mistakes it for a controlled study. What we can say with more confidence is the direction: skill-guided iteration costs more and produces a visibly more considered result, a pattern that shows up across every design-skill comparison we’ve run less formally in normal testing.

Why not just prompt Claude to “avoid gradient-text and generic AI design”? You can, and it’ll help some. But a one-line instruction doesn’t carry the reasoning a full skill does, the specific palette logic, the type scale rules, the checklist the model iterates against. Our full test protocol covers why prompt-level instructions and skill-level ones tend to produce different depths of result even when they point at the same goal.

How does this compare to Claude’s output on other kinds of tasks? Design tasks are the case where a skill has the most obvious room to help, because “does this look distinctive” is legible even without a scorecard. Our other Skill Bench entries test skills against a Telegram bot build, a debugging session, and a script audit, three domains where the win, if there is one, looks different from a nicer palette. See the full methodology for how we score across all four.

We picked this brief because a landing page makes a design skill’s case for itself without any interpretation required. Look at the two pages side by side and the palette, the gradient count, and the type discipline tell you everything the token table can’t. The next entry in this series trades that visual clarity for something harder to eyeball: a working bot, where “better” has to be judged by whether the thing runs.