oh-my-design-cliv2.0.0

A design system your coding agent can actually hold.

Most AI UI work starts from a prompt and ends with a screen nobody can defend. This CLI installs the missing middle: a philosophy you declare, a decision table that turns it into tokens, component contracts with states and accessibility, gates that catch the failures AI keeps repeating — and omd book to read the whole thing back.

$npx oh-my-design-cli@latest
Official docs

MIT. No API key, daemon, or MCP server for the core workflows — inference stays in the coding-agent session you already have.

What you get back

Three artifacts, all of them files in your repository.

DESIGN.md

A portable contract, not a config file.

Your philosophy with the sacrifices spelled out, a decision table where every choice carries an id, and tokens that point back at the decision that produced them. It stays useful pasted into a plain chat, and a designer can read it to find out why a value is what it is.

Read the spec

A design system, not a theme

Tokens, component contracts, and states.

Every component ships an anatomy, a state matrix — including the states that deliberately do not apply and the reason — an accessibility contract, and the token slots your decisions fill. Contrast pairs are declared, so they can be measured rather than assumed.

Browse 93 contracts

omd book

Your system, browsable on a local port.

Run one command and read the system back: each token beside its decision, component state matrices with their reasons, contrast measured live against the pairs you declared, and which presets your build drew from. --static writes a single HTML file for handoff.

See the command

Read your own system

npx oh-my-design-cli@latest book            # http://localhost:6060
npx oh-my-design-cli@latest book --static ./out   # standalone HTML for handoff

Storybook renders stories. This renders the contract — including the contrast measured against the pairs your system promised, so a regression shows up as a number instead of a feeling.

Why it is different

Six things that change what the agent produces.

Philosophy first, values second

The chain runs philosophy → decision table → tokens → component specs → layout grammar → build. A token value with no decision behind it fails a gate, so the system cannot quietly become a pile of improvised numbers.

A floor made of validated contracts

93 presets across four layers — fundamentals, primitives mapped to real shadcn/ui and Radix components with their ARIA APG patterns, screen genres, and reference-derived flavors. The agent selects and derives instead of inventing from zero.

Gates that name the failure

Numbered anti-slop gates cover the things AI-generated UI gets wrong in the same way every time: serif fallbacks on Korean text, focus rings on mouse clicks, native select popups, disabled states faked with opacity, wide viewports left empty. Mechanically checkable ones must be grep-verified.

Judged on screens, not source

The build renders, a critique reads the rendered screens and produces a numbered punch list, and the repair happens inside the existing system. Source-only self-grading is what lets a broken screen score well.

Provenance you can audit

440 company references ship with the package, quality-graded, with evidence for their claims. Unknown values stay absent instead of becoming plausible defaults — a missing brand fact is never filled in with a guess.

Files you own

Everything above is markdown and JSON inside your repo. No daemon, no MCP server, no API key for the core workflows — inference stays in the coding-agent session you already pay for.

Next to the alternatives

A component kit and a UI skill both solve real problems. They solve different ones.

 Prompt onlyComponent kitOther UI skillsoh-my-design
Consistent result across runsNoYesPartlyYes
Looks like your product, not the libraryPartlyNoPartlyYes
Every value traceable to a decisionNoNoNoYes
Accessibility contract per componentNoYesPartlyYes
Anti-slop gates by numberNoNoPartlyYes
Verified against rendered screensNoNoNoYes
Portable spec you can hand to a designerNoNoPartlyYes
Browse the system locallyNoPartlyNoYes

shadcn/ui gives you the structure and it is genuinely good at that. The preset layer maps onto it rather than replacing it: the contract says which values must come from your decision table instead of a library default, so two products built on the same primitives stop looking like the same product.

The longer shadcn comparison

What comes out

Three products built by the same harness from three different declared philosophies. Same gates, same preset floor — deliberately not the same face.

Home-interior commerce — a full page produced by the harness

Home-interior commerce

Bento home, three-cut galleries, rating distributions, magazine article wells.

Local marketplace — a full page produced by the harness

Local marketplace

Dense scannable rows, status tokens, trust indicator with its basis, dimmed sold items.

Fashion editorial — a full page produced by the harness

Fashion editorial

Image-dominant grid, ranking carousel with a linked list, honest sale-price hierarchy.

Each shipped with its own DESIGN.md and runs with npm run dev.

In v2.0.0, all of it is yours to change

A design system you cannot argue with is just someone else's taste with your logo on it. Every layer here is a file you can edit, and the build has to justify itself against whatever you put there.

Rewrite the philosophy

The stance and its sacrifices are yours to state. Change them and the decision table, the tokens, and the components follow — that is the whole point of deriving instead of theming.

Fork or extend the presets

Presets are markdown contracts in your repo. Add a genre your product needs, tighten a primitive to your accessibility bar, or drop one entirely and record why.

Tune the gates

Gates are a numbered list, not a black box. Raise a threshold, add a rule your team keeps re-learning in code review, and the next build has to answer for it.

Bring your own references

The catalog is data. Point the workflow at your own brand evidence and the derivation runs on that instead of a public reference.

Why that matters: taste you cannot inspect cannot be improved. When the rule is written down and numbered, a disagreement becomes an edit instead of another round of "make it feel more premium".

Keep going