Design systems
What the design tool answers, the curated design-system rows behind it, and the fields each system is described by.
Design is the part of a build where an agent's defaults cost the most: a screen assembled from whatever the model remembers looks plausible and does not match anything else in the product. Wellworn splits the problem in two. The design tool serves screen-level verdicts, and a curated list of design systems sits underneath as the set of things those verdicts can pick from.
What the tool answers
design searches verdicts of kind design: a question about a screen, a pick, the condition under which the alternative wins, the anti-patterns to avoid, and the same provenance every other verdict carries. It returns the same compact block as recommend.
No design verdict is published yet, so every call answers with the miss line today. The list below is readable now, on wellworn.dev/design, and needs no call at all.
The systems
The seed file holds 24 systems. Two of them, Mantine and Chakra UI, share a slug with a library entry an earlier verdict created, and the seeder refuses to overwrite a row of a different type, so the site serves 22 today. Both are still reachable as library entries; they just do not appear in the design list.
Every row was read off the vendor's own documentation, its GitHub repository, or the npm registry, and the file records the date and how it was checked:
verified_on: 2026-09-08
verified_by: manual check of vendor docs, GitHub API and registry.npmjs.orgThe file records an open-source licence for all 24: 18 MIT, 5 Apache-2.0, and Polaris under Shopify's own MIT file. Nine of the rows are React only; the rest cover Vue, Svelte, Solid, Angular, web components, or plain CSS.
How a system is described
Nine fields, chosen so an agent can rule a system in or out without opening its site.
| Field | What it records |
|---|---|
name, slug | Display name and the identifier the row is stored under |
website, repo | The documentation site and the source repository |
license | The actual licence string, not a category |
frameworks | Which frameworks it ships components for; also used as the row's tags |
style | How styling arrives: Tailwind utilities, a prebuilt stylesheet, CSS variables, or nothing at all |
tokens | Whether design tokens are exposed to theme with. 19 of 24 expose them |
agent | First-party AI tooling only, such as a vendor MCP server or an llms.txt |
note | One sentence on the tradeoff, the current version, or the recent change that matters |
Two of those fields carry most of the weight. style decides whether adopting the system means adopting a CSS approach: copying component source into your repository is a different commitment from importing one stylesheet.
agent is written strictly. It names support the maintainers publish themselves; a community MCP server that the maintainers do not ship reads as none first-party, which is the answer for 9 of the 24 rows. An agent looking for a system it can query rather than guess at should read this field first.
Why notes carry dates and versions
The note field is one sentence, and the sentence has to be the one that dates the row: the version the system is at, the primitive layer it switched to, the maintainer organisation it moved under. A note that would read the same in a year is a note that says nothing, and it is also a note nobody will notice has gone stale. Rows are re-read by hand rather than by a job, so the verified_on date at the top of the file is the age of every claim in it.
Correcting a row
The file is in the private platform repository rather than the public corpus, so the path is email to support@wellworn.dev with the system and what changed. A row is corrected by re-seeding, which is idempotent by slug: a second run updates the fields and leaves the identifier alone.