Where your brand lives
Everything that makes your product look like yours starts in a DESIGN.md file. You write your brand's primitive choices — color, typography, spacing, radius, motion, focus ring — and the system carries them everywhere your UI runs.
You keep one file per theme: DESIGN.md (light), DESIGN.dark.md, and DESIGN.cb.md (color-blind). They live together under your brand folder.
Change a brand value
- Open your brand file, e.g. brands/wyrd/DESIGN.md.
- Edit a primitive — say your brand's primary color.
- Build your tokens to regenerate every artifact.
- Check the result: the build tells you if a color fails contrast or a value is orphaned.
$EDITOR brands/wyrd/DESIGN.md
pnpm build:tokens
pnpm check:tokens What you get out
From that one file, you get token artifacts ready to drop into either platform — CSS custom properties and TypeScript for the web, Dart for Flutter — generated per theme. You never hand-maintain three copies.
Lint your brand file
Your DESIGN.md is checked against a format spec, on demand and in the build. Run pnpm lint:design-md (or design-md lint --design brands/wyrd/DESIGN.md to lint one file, or --brand-dir to lint every theme) and it flags broken references, WCAG contrast failures, and orphaned tokens — so brand mistakes surface while you author, not in your shipped UI.
Your three themes
Light and dark are yours to author directly. The color-blind theme is seeded for you from your brand — the tooling finds clashing hues and gives you a strong starting point — and then you hand-tune the checked-in DESIGN.cb.md until it reads well. The tool proposes; your authored theme is the source of truth.
When a component needs a value you haven't defined
- Don't hard-code it in CSS or Dart — the coverage check will flag it.
- Add the primitive to your brand so every platform and theme gets it.
- Rebuild tokens and re-run the check.