Yelmo
Learn

design.md, designer.md, and the judgment in between.

01

design.md, designer.md, and the judgment in between.

The format Google open-sourced describes a brand. Yelmo describes the designer behind it. Where the difference matters.

Google's design.md spec is one of the more useful things to happen to AI design in 2026. It's a plain-text document that describes a brand's visual identity — colors, typography, layout, components, do's and don'ts. You drop it in your repo and any coding agent that reads it produces UI that respects the system.

It's a great spec. It's also not what Yelmo does.

The spec is brand-bound. One design.md per visual identity. Stripe has one. Linear has one. Vercel has one. The reader is the agent; the author is the design system.

Yelmo's design.md is person-bound. One per designer. Danny has one. You have one. The reader is still the agent, but the author is the human behind the work.

The difference matters because design isn't only the system. Judgment is what happens when you understand the system so well you know when to break it. The system tells your agent the rules. Your design.md tells your agent why those rules exist, what they don't cover, and when to ignore them.

That's the gap Yelmo lives in. Google's design.md describes the system. Yelmo's design.md describes the criteria that shaped it.

Concretely, the sections in Yelmo's design.md are things Google's spec doesn't cover:

  • How I work — process, pacing, how you collaborate.
  • What I look for — patterns that stop you, references you save, criteria for "good".
  • Influences — people, products, ideas that shaped your view.

If you publish a Google design.md, you're documenting a brand. If you publish a Yelmo design.md, you're documenting a designer. Both are useful. Yelmo is for the second.

Now write yours → Get started Browse real ones → /design

Next lesson

Anatomy of your design.md.

Five sections, twenty minutes. What to put in each, what to leave out, and how to make it useful to an agent.