Design-token and brand tooling

An application declares its design system as a configuration file, and wildo design-tokens generate turns it into the custom-property block every frontend surface reads. A separate command pushes the application’s accepted brand assets to each site that shows them. Both write into files a developer also edits, so both write into a marked region rather than owning the whole file.

The problem it solves

Colours, spacing, radii and typography end up duplicated across a product’s surfaces: the application, the marketing site, the documentation portal, and the emails. Each copy is edited separately, so within a few months they disagree, and the disagreement is the kind nobody files a bug about because each surface looks fine on its own.

Generating them from one declaration would be the obvious answer if not for one thing: the stylesheet is not only generated content. A developer has real hand-written CSS in the same file, and a generator that owns the file destroys it. The same is true of brand assets, which land in several served directories and in the head of several sites, and which may have been supplied by a person rather than produced by a generator.

What it does

Two commands turn declared design decisions into the files the surfaces actually read: the design system into stylesheet variables, and the accepted brand assets out to every surface that serves them.

The design system is authored at a fixed path. Generating loads it, produces the custom-property declarations, and replaces the content between a start and an end marker in the existing stylesheet, leaving everything outside the markers untouched. A separate step inserts that marked region into a stylesheet that does not yet have one, and another checks the authored configuration. The generated region carries its own notice saying it is generated and naming the command that regenerates it.

Brand propagation reads the COMMITTED source of truth for the application’s resolved assets, never a staging directory, and runs every destination it discovers. The destinations are found by file rather than enumerated in the command, so a new surface plugs in by adding one file — demonstrated rather than promised: the destination that stamps the assets into the backend’s runtime configuration was described as a future addition and was picked up without any edit to the command.

Each destination copies the asset files into one surface’s served directory and reconciles that surface’s references to them. Because it only ever reads the committed assets, it runs identically whether they were generated or supplied by hand, and it is a clean no-op when there are none.

What you decide

wildo design-tokens generate
wildo brand propagate

with a dry run that prints the whole plan, and a flag to run one destination.

Limits

The token generator writes one region in one stylesheet per surface. It does not distribute the design system to the other surfaces itself; each surface reads the tokens from the generated block in its own file.

Brand propagation reaches five destinations today — the application’s public assets, the marketing site’s public assets, the site’s social-preview images, the documentation site’s static assets, and the backend’s runtime configuration. An email destination and a structured-data destination are named in the command’s own notes as absent, and neither is implemented.

Neither command validates the result visually. A design system that parses and generates can still produce an unreadable contrast ratio.