After Code Connect: bidirectional design systems

Main point: Code Connect and MCP carry design into code. With the Figma CLI, a personal access token and a governance skill, decisions made in code can now flow back into the Figma library, on purpose and with review.

Recap

In The Figma-to-code gap is a solved problem, I said the flow mostly runs one way. That's still the right default. What's missing is a governed way to push a code decision back into the canonical Figma component.

Figma CLI with a token

A personal access token lets the CLI do the exact, boring jobs: read variable collections, find the Button component's nodes, apply a radius. It doesn't replace judgment. It removes copying errors.

The harness: rules as steps

1. Name the contract: which Figma component maps to which repo files (src/components/ui/button.tsx, tokens in src/os/design-system/tokens/)
2. Change code first (for example the rounded-lg class, or the --uds-radius-* tokens in base.css)
3. Update a manifest of what the Button takes from Figma
4. Only then update Figma, with a named reviewer

No Figma write without a matching repo change.

A bridge file

A file like src/components/ui/figma-button.tsx maps Figma variable names to CSS variables:

export const figmaButtonVariables = {  radius: { figma: "radius/button", cssVar: "--uds-radius-md" as const },} as const

It gives the assistant and CLI one place to compare when Figma and code disagree. It also works in reverse: pull variables from Figma, refresh the file, and let CI check every --uds-* still exists.

Honest limits

• It's a process, not a setting. Someone must own conflicts.
• Token access must be scoped and audited.
• Start with one component (Button) and one value type (radius).

CLI for precision, MCP for context, and a harness for the rules.

Series: The design organisation as a codebase and A first-principles approach to design in the age of AI.