A note from the builders

Where we think the harness stands

Before we settled on this shape, we studied the harnesses we respect and measured ours against them. With the models available today, we think ours compares well. We are proud of that.

We are also careful with the word "today". Models improve every few months. Each improvement moves the line between what a harness must supply and what a model brings on its own. Some of the scaffolding we built this year will be unnecessary next year. We would rather write that down than let this site imply we found the answer. We found an answer that works today, and we keep checking whether it still does.

Standards that give your agent eyes

The part of this harness we defend hardest is the standards. The obvious version would have been a linter: measurable rules, pass or fail, done. Design does not work that way. A harness that pretends otherwise enforces whatever a script can count and loses the rest.

So the standards range the way design judgment ranges, from deterministic to abstract. One end holds rules a script can measure: contrast floors, target sizes, and steps on the type scale. The other end holds calls that need judgment: whether a page reads as generated, or whether motion tells the truth about what changed. Every standard declares which kind it is, how it gets checked, and what waiving it costs. That range is what gives your agent eyes: a way of reading a screen that holds the measurable and the judged at once.

We also built the standards to be read. Every standard is a page a designer can open and argue with. The site publishes the same catalogue the harness checks against, with product-neutral wording, from a pinned dx-harness commit. A standard that only tooling can read is one your team will ignore, and your team would be right to.

Why DESIGN.md lives in your repo

We could have kept every product's design language in one central place. We chose the opposite: the design language skill interviews you, reads your code, and writes a DESIGN.md that stays in your product's repo.

We chose it because your context is not our context. Every team ships under different constraints: a different audience, a different codebase, and a different history of decisions that made sense at the time. A central file would flatten those differences or go stale trying to track them. A file in your repo evolves the way the rest of your product does, through pull requests, by the people closest to the work.

It also keeps the choice of design system yours. If your team already has one, DESIGN.md points at it. The standards still hold the L0 floors that protect users: contrast, keyboard access, form labels, and destructive actions that show their consequences first. Anything above L0 can change through a documented waiver, or through a standing override in your DESIGN.md with your team's named approver.

That is the trade we are trying to make: consistent where inconsistency would hurt users, flexible where your product knows better than we do.

Where the harness came from

This site is about design, and design is what the harness ships. It did not start there. Before the design harness we built an engineering one. Its review loops, issue skills, and repo conventions taught us how agents behave inside a codebase. The design harness inherits that shape: everything is a file in a repo, checkable and versioned.

The habits from both crafts still show: we care how a standard reads and how it runs. We want our products to stay worth using at the speed and scale that agents make possible.

What we expect to change

We built the structure to hold more than it holds today. The standards can carry another design system's rules. The skills are a set we curate, and we expect to add some and retire others. If a better way of working with agents appears, the harness should be able to absorb it. If it cannot, we will discard the harness before we discard the better way.

Writing that sentence is cheap, so here is what meaning it costs us: re-reading our own decisions when a new model ships, retiring work we were fond of, and telling you when something here is out of date instead of quietly leaving it up. What stays constant is the job underneath. We adjust how we support teams working with AI, and we keep that support within reach of people who do not write code every day.

If this page stops being true, the fix is to change the harness, not the page.