Design System (DESIGN.md)
UAP implements the DESIGN.md format — YAML design tokens (colors, typography, spacing, rounded, components) plus prose rationale — as a project's persistent visual identity for agents.
When to use
Before any UI/UX work: building or editing components, CSS/SCSS, Tailwind, styling, colors, typography, layout, themes, or design reviews.
Workflow
Ensure a DESIGN.md exists. If the project has none, derive one from the existing UI:
uap design interrogate # scans CSS vars, Tailwind, theme files, usageThis writes
DESIGN.md(refine its prose + token roles) and the gate's allow-list.uap/design-tokens.json.Apply the tokens to new UI. Use the DESIGN.md color/spacing/typography tokens (or CSS
var(--…)/{token.ref}references) — never hardcode off-token hex colors or off-scale spacing. The reactor injects the active design summary automatically when it detects UI work.Keep it in sync. After editing DESIGN.md tokens, regenerate the gate allow-list:
uap design syncValidate against the spec (uses the OSS
@google/design.mdCLI — WCAG contrast, broken token refs, structure):uap design lint
Enforcement (hard gate)
The design-token-gate policy blocks UI edits (.css/.scss/.tsx/.jsx/.vue/ .svelte/.html/.astro) that introduce colors or spacing not in the design
system. To resolve a block: use an existing token, add the new value to
DESIGN.md then uap design sync, or bypass once with UAP_DESIGN_GATE_OFF=1.
The gate is inactive (fails open) for projects without a DESIGN.md.
Verification
uap design context # what the agent is told for UI work
uap design check --file path/to/Component.tsx # would this edit be blocked?