Turn the direction into a specification and tokens

Your direction for the bakery says one action, in the awning green. Your agent writes one hex value on the home page, a slightly different one on the next page, and a bluer one in the footer. Each is close. None is the color. A brief describes the direction. A specification turns it into values the build can't approximate.

A specification holds four things. Tokens, the named values for type, color and spacing. Component rules. The responsive rules you wrote at the structure stage. And the checks: how anyone will know the build followed it. Tokens are the part people know about. The checks are what make the rest worth writing.

Here's the start of the bakery's tokens file. Colors named by job, from the color lesson. The five type sizes, from the type lesson. And a spacing scale: five steps, set from the size of the reading text, so every gap on every page comes from one of five values. If a value isn't in this file, it shouldn't be in the build.

Name every token by its job. A token called 'red' breaks the day the brand changes color. 'Space seventeen' tells nobody when to use it. 'Text extra large' invites an extra-extra-large. Named by job, the file reads as a set of decisions, and a wrong use is visible: action on a heading is obviously a mistake.

Then label where each value came from: the brand's own evidence, the brief, the accessibility floor, or your own choice. The green says provisional, because it was read off a photo. The gold names the printer's proof. You're done when every color, size and gap in the file has a name and a source.

The Swiss Style kit has the same habit, with four labels. Required means break it and it isn't Swiss. Period means it was done in period practice, a defensible default. Modern is current good practice and no part of the language. Ours means the kit's authors chose it, so change it freely. Look at the font line: the class of typeface is required, the exact stack is ours.

Component rules use the tokens and cover every state. Here's the bakery's action button: its fill, its label with the ratio, what hover and focus look like, what happens while an order is sending, and how many may appear. That last line comes straight from the direction: one Order ahead button per page. When the agent puts a second one beside the photo, the spec says no.

The responsive rules from your structure work belong in the spec as well, written as rules rather than three layouts. The queue photo stays first at every width, with the headline under it. Nothing hides on a phone without a stated reason. Write the 'never changes' list first. It's the one agents most need.

Then define the checks, in two kinds. Some are mechanical: no raw color value outside the tokens file, no font size off the type scale, no gap off the spacing scale, every pair passing contrast. A script or an agent can run those. Others need a person to look. Tell the agent to score only the mechanical checks and leave the visual ones unjudged rather than guess. Don't add the results into one total, because failing a required rule and departing from your own choice aren't the same result. And end the spec with a short list of rules for the agent, such as never inventing a value the file doesn't hold.

If the build can't be checked against it, it isn't a spec yet.