§1The claim worth testing
There is a fast-growing shelf of open-source "design taste" skills for coding agents right now, things like taste-skill, styleseed and claude-design. They all promise the same thing: stop your AI agent shipping generic, obviously-generated frontends. It is easy to dismiss the lot as a longer prompt in a trench coat.
One of them makes a sharper, testable claim, and it is the one worth checking. StyleSeed openly publishes that its rule list on its own did not reliably help. In their own benchmark the raw rules moved Codex up a little and moved Claude Code down by nearly four points. What helped was wrapping the rules in a scored gate: build the screen, score it against a rubric, and revise until it clears a bar before a human ever sees it. That lines up with everything we already believe about gates, which is exactly why we wanted to test it on our own work rather than take it on faith.
§2The test
One functional spec: a small B2B analytics dashboard, four KPI cards, a revenue chart, a table of recent transactions, realistic fake data, one self-contained HTML file. We handed that identical spec to the same model (Claude Opus 4.8) twice.
Arm A got the spec and nothing else: build it the way you normally would. Arm B got the spec plus StyleSeed's method, the "operations-console" grammar and the seven-category rubric, and was told to self-score and revise until it cleared 85 before finishing. Then, to keep ourselves honest, a third agent scored both files blind against the same rubric, citing line numbers, without being told which arm produced which.
§3The result
The blind judge put the plain build at 51 out of 100, an F, and the StyleSeed build at 97, an A. Here is the same dashboard, same model, same prompt, side by side.
The gap is not the judge being generous. The fixes are real, and they are the nameable tells that make a UI read as "generated":
- The plain build coloured the "Paid" status green on almost every row. The gated build made a normal status neutral grey and reserved colour for the two rows that actually needed attention, the Failed and the Pending. Status colour should mark the minority, not wash the whole table.
- The plain build had no loading, empty or error state at all. The gated build shipped all three on the data surface, with the empty state naming a next action.
- The plain build was four equal-weight KPI tiles with no focal point. The gated build made Revenue the clear primary and let the others recede.
§4Three honest caveats
This is one build per arm, not a benchmark, so read the numbers as a single vivid data point, not an average. And our plain arm scored unusually low because it clamped to zero on two whole categories, no data states and leaky status colour, which dragged the total down hard. A luckier plain run scores higher. So treat 46 points as near the ceiling of the effect, not its typical size. What is repeatable is the kind of win: the structural tells got fixed.
Second, the gated arm was handed the very rubric it was later judged on, so of course it scores well against it. That is why the screenshots matter more than the number. Look at the two: the difference is plainly visible to a human who has never heard of the rubric. The gate is not gaming a metric, it is removing real defects.
Third, and this is the actual finding: the active ingredient is the gate, not the rules. A rule list pasted into a prompt is easy for a model to nod at and ignore, which is why StyleSeed's own numbers show raw rules can make things worse. A render, score, revise loop is not ignorable, because nothing ships until the score clears the bar. We keep relearning this in every domain we work in. It is why we gate code review, why we gate our eval panel, why we red-teamed our own agents. Design is just one more place a scored floor beats a longer instruction.
§5What we'll actually do with it
Two decisions, split by whether the work is brand-locked. For un-branded work, a fresh internal dashboard, a prototype, a quick throwaway tool UI, we will wire a design-score gate into the build, because that is exactly where we currently wing it and ship the first draft. That is the gap this fills.
For brand-locked work, our own product surfaces and client deliverables that already run tight design systems, we will not take a third-party skill's default look. The move there is to feed our own tokens in as the grammar and keep the gate, so the score enforces our system rather than someone else's taste. A generic taste skill pointed at a locked brand fights it; a gate pointed at your own tokens defends it.
You do not have to install this specific skill, and it is early and rough in places. The transferable lesson is smaller and more durable than any one tool: for UI, as for code and for evals, a scored gate beats a longer prompt. Build the second check, not the bigger instruction.