A Style Guide Gets Read Once. A Skill Runs on Every Edit.

Most teams have a style guide. A Notion page or a Confluence doc or a Figma library with annotations. It captures decisions about spacing and color and typography and interaction patterns.

It gets read once during onboarding. Then it's referenced occasionally, when someone thinks to check it.

The web-design-guidelines skill from vercel-labs solves a different problem.

What 100 Rules Means in Practice

At 285,600 installs, web-design-guidelines is one of the highest-installed skills in the vercel-labs/agent-skills collection. The skill encodes 100 rules for what good UI looks like — covering layout hierarchy, whitespace, typography contrast, color usage, component spacing, interaction feedback, and more.

100 rules is a lot. It's deliberately comprehensive. The goal isn't to give the agent a handful of principles to philosophically apply. It's to cover enough ground that most of what a design-aware developer would catch in a review is already running as an active check.

That density matters. A sparse set of principles invites interpretation. 100 specific rules leave less room for the agent to interpolate incorrectly.

The Compliance Gap

Here's the problem style guides have always had: there's a gap between writing the standard and applying it. The standard lives in one place. The work happens somewhere else. The person doing the work has to remember to consult the standard, recognize when it applies, and correctly translate it into the decision at hand.

For human developers, this is manageable but imperfect. Design consistency in most codebases degrades over time — not because developers don't care about it, but because the cost of consulting the standard on every small decision is too high. Margins become inconsistent. Typography scales drift. Padding values get hardcoded because looking up the spacing token takes time.

An agent with the skill loaded doesn't have this problem. The 100 rules aren't in a separate document to consult. They're in the context. Every component the agent touches, it's applying those rules as part of the edit rather than as a separate review pass.

The Shift From Review to Prevention

The more consequential change is architectural. When design guidelines live in a style guide, the workflow is: build, then review, then fix. The review catches the drift. The fix costs rework.

When guidelines live in a skill that runs on every edit, the workflow is: build correctly once. The rule is active at the moment the decision gets made, not after.

This sounds small. It isn't. In my own experience, the friction of design review — even light review — creates pressure to batch it, skip it for smaller changes, or defer it. The result is accumulated inconsistency that's expensive to fix wholesale.

The skill format eliminates the category of "small change that didn't feel worth reviewing." All changes get the rules applied.

What Makes the Vercel Version Worth Using

The honest question about any design guideline set is: whose taste is this?

The vercel-labs version is opinionated in a specific direction: fast-loading, high-contrast, clean hierarchy, whitespace-generous. These are the aesthetic patterns that show up in Vercel's own products and in the apps their highest-traffic customers build.

That's a coherent aesthetic position. You might not agree with every rule — but it's internally consistent, which means the agent produces internally consistent output. Consistency is more valuable than perfection on any individual rule.

If you have strong aesthetic opinions that diverge from Vercel's, you can extend or override specific rules. The skill gives you a baseline that's better than none and better than vague principles.

A style guide you have to remember to consult is a recommendation. A skill that runs on every edit is a constraint. Most codebases would benefit from the constraint.

---

Part of the AI Skill Daily series — skills worth understanding, one at a time.