Skip to content
Design Token Authority

Workflow rail

The workflow at a glance: a change is made on one side (Figma Variables, a token file or an agent), crosses into the repository, and runs through the steps of the pull request. Two sides meeting in a pull request, not a ring of steps and not numbered. The landing page shows it right below the hero, under the “How it works” anchor.

Two sides meeting in a pull request

Light
where the change is made
Change

In Figma Variables, in a token file, or by an agent.

into the repository

in the pull request
  1. Check

    Structure and names, against your rules.

  2. Build

    Every output, for every brand and mode.

  3. Diff

    Before and after, each difference named by token.

  4. Decide

    A person approves by token.

A fix goes back to whichever side caused it: a value in Figma, or a component in code.finds the hard-coded ones

Graphite
where the change is made
Change

In Figma Variables, in a token file, or by an agent.

into the repository

in the pull request
  1. Check

    Structure and names, against your rules.

  2. Build

    Every output, for every brand and mode.

  3. Diff

    Before and after, each difference named by token.

  4. Decide

    A person approves by token.

A fix goes back to whichever side caused it: a value in Figma, or a component in code.finds the hard-coded ones

Story: /stories/workflow-rail/default/

Guidelines

Section titled “Guidelines”
  • Two sides, one crossing. The change on the left under a dashed rail bracket labelled where it is made; its command (dta pull) on the crossing; the pull request under a solid border-strong bracket. Inside it the steps in order, with a thin fg-subtle arrow between them.
  • Each step: a one-word label (title type), one short line in fg-muted, and its command as a command button. A step without a command (the person deciding) has none; do not invent one.
  • No arrow back. The return line under the pull request says where a fix goes (“a fix goes back to whichever side caused it”) and may carry a command (dta audit). The workflow is not a loop to draw.
  • Unnumbered. On the landing page the scene kickers are the only numbers. The steps are an ordered list for screen readers; the section has a visually hidden heading (title).
  • Layout: one row when the container is 960px or wider; below that a vertical list in which the pull request’s bracket becomes a 2px left rule (its label, steps and return line inside it) and the change side’s a dashed one. The change side takes one part of the width to the pull request’s three (beyond what the chips need), so its label stays on one line on a 1280px screen; between 960 and about 1150px of container the pull request’s chips claim the width and the label may wrap. Command chips do not wrap, so the row needs that width; in the side-by-side theme panels of the docs and stories the list is what you see.
  • Surface: rules and type only, no card, no shadow, no grid paper, no motion. Text pairs reach AAA (7:1) in both themes.

Tokens used

Section titled “Tokens used”

Read from the component’s source:

--border-strong--fg-default--fg-muted--fg-subtle--font-mono--font-sans--rail--space-1--space-10--space-2--space-3--space-4--space-6--space-8--stroke-ink--type-body-sm-line-height--type-body-sm-size--type-meta-letter-spacing--type-meta-line-height--type-meta-size--type-title-line-height--type-title-size--type-title-weight