My coding agent kept building the same landing page, so I wrote it a design skill (and lost my own benchmark first)

Ask an agent for a landing page and you'll usually get the same one. A centred headline, a purple gradient, three cards with icons, and a row of numbers nobody gave it, like "10,000+ teams".

Ask it to add a screen to an app you already have and it often ignores your components and builds its own.

I build small web products and the odd client site, mostly with Claude Code, and this was the part of the job I kept redoing by hand.

How I used to fix it

For a while my prompts got longer and longer. I had a note I pasted at the start of every UI task: no purple, no gradient hero, no three-card feature row, no fake stats, use a serif for headings. When that didn't work I'd run the same prompt four or five times and keep the least generic one, then spend an hour restyling it myself. That hour was the real cost, and it never got shorter.

The bans were the interesting failure. Every time I told the agent not to do something, it found a new favourite. No purple became cream and terracotta. No Inter became the same two serifs on every page. I wasn't removing the default, I was moving it.

Why I built a skill

What I wanted wasn't a better list of fonts. A named pick just becomes the next thing every AI page has. I wanted the agent to make design decisions the way a person does: start from what the visitor came to do, find something specific to this product, and check the result.

Agent skills are a good fit for that. A skill is a folder of instructions the agent loads when the task matches, so it costs nothing until you ask for UI. GradientDeck is one of those, free and MIT licensed.

Then I tested it, and it lost

I didn't want to judge it from a few nice screenshots, so I built a small benchmark. Same brief, same model, one run with the skill and one without. The pages were shown to me in blind pairs and I picked the one I'd ship.

In the first two rounds, on brand-new sites, I picked the page made without the skill about 22 times to 8.

The funny part: when I had other agents judge the same pairs, they preferred the skill pages 69 to 76% of the time. Agent judges were not a stand-in for my eye at all.

Looking at the losers, the reasons were plain:

• Skill pages showed gaps like "[to be supplied]" where the agent didn't have a fact. Honest, but it looked unfinished.
• The skill pushed the model away from layouts it already does well, so spacing got awkward.
• The review step was supposed to catch this, but it almost never ran. One review file was read across 108 runs.

So I changed the workflow to: draft with your own judgement, taste-test the draft, then fix. Missing facts get written around instead of printed as placeholders. Ordinary conventions, like product cards on a shop, stopped counting as mistakes.

After that the skill tied or narrowly beat no-skill in the pairs I ran. That's not a landslide, and I'd rather say so. The goal was never to beat a strong model at its own game. It was to never make a strong model worse, and to lift the weaker ones.

How it works now

When you ask for a new page, the agent:

1. Starts with what the visitor came to do. That goes at the top of the page, on a computer and on a phone.
2. Finds one idea from the product's own world. Something visitors already know. A mail-in shoe repair became a map of where soles wear out. An invoicing tool became a railway departure board. A children's dentist became a door-frame growth chart.
3. Plans the look before code. Fonts, colours, photos and one detail people will remember go into .gradientdeck/pages/<page>.md.
4. Checks its own work at desktop, tablet and phone sizes, and a small script flags things like an uncredited photo. It fixes what fails.

Here's the same brief with and without it:

In a project that already has a look, it goes the other way. Your colours, type, components and the nearest similar page come first. It says what it's adding and why. A settings screen gets almost no new ideas. A launch page gets one bold one.

A few rules it won't bend:

• No invented proof. No fake logos, quotes, ratings or user counts. If a page needs a fact you didn't give it, it writes around the gap and tells you what to fill in.
• Real photos, credited. It ships with a list of 755 openly licensed Wikimedia Commons photos and credits each one it uses. No stock sites.
• An accessibility floor. Readable contrast, visible focus, a calmer version of every animation for reduced motion, tap targets that fit a thumb.

How I use it day to day

npx gradientdeck install

Then I ask for UI like I normally would. The skill joins in on its own. When I want something specific, I name it:

• reroll bolder when a page is fine but forgettable
• deslop after a change that came out generic
• extract to write my existing design system down as a DESIGN.md
• polish for a last pass on spacing, states and focus

Last week I asked for a landing page for a friend's pottery class. Without the skill I'd have got a beige page with a serif headline and a stock photo of hands on clay. This time the agent laid the class times out like a kiln firing log, put the booking form right under the first heading, and used a credited Commons photo of a real wheel-thrown bowl. I changed the copy and one colour. That was it.

What it can't do

• If your agent has no browser tool, it can't look at the page. It reviews the code and tells you it couldn't look. Code-only review misses spacing and alignment problems.
• It's young. Version 0.2.0 at the time of writing, and the benchmark keeps finding things.

The installer has no dependencies, makes no network requests and collects nothing. It works with Claude Code, Codex, Cursor, Copilot and OpenCode.

If you try it, I'd like to see what it builds for you, good or bad. The bad ones are how the benchmark gets better.

Repo: https://github.com/VenoM9078/gradientdeck-skill
Site: https://skill.gradientdeck.com