Design System

Backend planning works because you can talk in interfaces. Frontend has no equivalent artifact, so look-and-feel survives three tickets and then drifts. This skill writes that artifact.

Everything splits along one asymmetry:

• The system is agreed upfront, because it is numbers. It lives in SYSTEM.md, inside this skill — never copied into a repo, never interviewed about, never re-litigated. It is what makes every project you build recognisably yours.
• The flavour is per repo, and its motifs are deferred, because prose cannot hold them. Vibes are discovered by building, not by answering questions. They land in the repo's DESIGN.md.

DESIGN.md holds intent; code holds values. A value that exists in code never appears in DESIGN.md — prose that duplicates a hex code loses to the stylesheet and rots silently. DESIGN.md records why 2× padding, why no flat scrim, why amber. Same division CONTEXT.md already keeps against the domain.

Where DESIGN.md lives

One DESIGN.md per brand, not per app. It sits at the highest point governing every surface it covers — repo root in a monorepo, app root in a single-app repo. Different density does not earn a second file; the Surfaces table handles that. A genuinely different brand does.

The single exception: if a React Native app is ever added, it gets its own DESIGN.md that transforms the CSS tokens into mobile ones. Until that app exists, tokens are CSS variables and nothing else.

Process