The situation almost every real frontend task is in: there is already a codebase, it already has conventions, and the new work has to fit into it rather than announce itself.
There is already a good skill for choosing an aesthetic. Claude Code ships one, it is thoughtful, and it is aimed at the blank page: what should this look like, what typography, what stops it reading as a template. If that is your problem, use that. Nothing here competes with it.
Almost no real frontend task is that task. The far more common one is: there is a codebase, it has conventions, and you are adding a screen to it. We wrote two skills for that situation and tested both. Only one survived.
The one that failed was about visual drift. The theory was that generated UI invents values: 14 pixels of padding among buttons with 16, a green picked on the spot instead of the one in the token file. The theory is right about human code. It turned out not to be right about a capable assistant looking at a token file, which conformed almost perfectly on its own. The skill saved two stray pixel values and nothing else, so it is not published.
The one that worked was about states. Interfaces get built for one situation: a moderate amount of well-formed data, loaded successfully, by a user with every permission, on a wide screen. Users spend a remarkable share of their time somewhere else. The first five minutes of every account are the empty state. Every typo in a search box is the no-results state, which is a different state again and constantly gets the same copy. Every slow network, every expired session, every seat limit, every name too long for its column.
Those do not throw, so nothing catches them, and they concentrate in exactly the moments where someone decides whether the product is any good. That gap turned out to be real and measurable: the assistant working alone covered 14 of 18 states, and missed the first-run empty state, per-item partial failure, the last-administrator guard, and keyboard focus after a deletion. All four are the kind that produce support tickets rather than stack traces.
Each skill was given a realistic task, then the identical task was run again with the skill removed. The two outputs were compared against a fixture with a known set of planted defects, so the difference is countable rather than a matter of opinion. If a skill did not make the output materially better, it is not on this page.
Each skill page carries the specific result: what the run without the skill found, what the run with it found, and where it still falls short. Back to all skills.