Front-end skills against the AI look

front-end

Ask a model for a landing page without mentioning design. It nearly always gives you something similar: a purple-to-blue gradient, rounded cards with a soft shadow, and a button that glows on hover. It works, but looks like every other site.

I see this as a setup problem, not a talent problem. If nobody chooses, the model uses the most likely option. In CSS, that option tends to be the same set of styles.

Choose the look before writing the first style

On my projects, LUMEN handles interfaces. LUMEN is the front-end agent. Before writing styles, it loads design skills, guides that help choose how an interface should look. I installed two on July 15. ui-ux-pro-max brings together styles, color palettes, font pairings, and UX, or user experience, guidance. The agent can search these references. The local version of high-end-visual-design adds an aesthetic direction and a set of tokens and components.

Tokens are named values for colors, spacing, and shapes that the interface reuses. On August 8, I added the glassmorphism, bento-ui, and neomorphism skills. I set all of them to load before any CSS, the language that defines a page's appearance. I also brought in nine motion skills from an upstream repository and pinned the version to a commit, a recorded version of the code. That keeps them from changing without my control. Some cannot be activated by the model on its own. They only run when I ask.

The order matters more than the list. If the agent reads a skill after writing CSS, it can only become a review comment. If it reads it first, the skill guides the work from the start. The agent uses a chosen palette, font pairing, and tokens instead of repeating the internet average.

What changes and what stays the same

The look changes. The automatic gradient gives way to choices about type, spacing, and depth. In my view, the token layer helps: colors, rounded corners, and spacing come from one place, and components reuse those values. Without it, every screen invents the purple again. The skill also works as a list of questions for the model to check.

But that does not make the code correct. A skill does not make the compiler report errors. Two problems from September show why.

A class that creates no CSS

On September 16, I found that Tailwind, a tool that generates CSS from code classes, accepts values outside its scale without generating CSS or giving a warning. The utility class duration-180 appeared 61 times across 20 files. The build, the step that prepares the project, finished in 7.70 s.

Tailwind reads the text in the code, compares each value with the theme scale, and only generates CSS for values it finds. Unknown text in className stays text. That is why there is no error. The class was in the code but not in the stylesheet. The build showed no problem. The fix is to declare the value in the theme scale or use an arbitrary value written directly in the class.

CSS order decides

The next day, another problem appeared. When two utility classes conflict, the one Tailwind writes last in the CSS file wins. The order of classes in className does not count. Putting the right class last in that list does not fix it. The code looks correct in review because reading from top to bottom suggests it should work.

A design skill cannot catch this. The error is not about appearance: there is a gap between what className says and the CSS the build creates.

Check the result, not just the code

The lesson was to check the result. After changing a style, open the generated CSS. Check that the rule is there and that it wins. This takes longer than reading the code change, but would have found the 61 cases before the build finished.

Skills help avoid the generic AI look. Only the generated CSS shows what they cannot see. A search for duration-180 in the final file would have found nothing. That would have revealed the problem the build missed.