Hand a design to a coding agent

A designer draws the thing on a whiteboard: the pages as frames, the references as pictures, the instructions as words, circles and arrows. Someone hands it to a coding agent. The agent needs to understand every part of it as she meant it, build it, and prove the build matches. Three tools do that, on the MCP connection your agent already uses.

1. Get the build spec#

get_build_spec turns the board into the plan a coding agent builds from:

• The brief: what is being built and for whom, her instructions, the do's and don'ts read from the markup, and her own description of the board.
• Screens: one per frame (or per area of a board without frames), each with its purpose, its layout in words with the measured sizes and gaps, its components, its copy word for word, and acceptance criteria the agent can check against a screenshot.
• Tokens: colours as hex with their role, type styles with family, size and weight, spacing from the measured gaps.
• Flows: what leads where, read from the arrows.
• Files: a sharp 2x picture of each screen and every reference picture at full resolution, as download links that last an hour.

It comes back as markdown and as JSON. A coding agent saves the markdown as DESIGN.md and each file at its path (screens/…, assets/…), so the repo carries the design beside the code. Every line cites the board elements it was read from.

2. Check the build against the board#

verify_against_board takes a screenshot of what was built (as an image, or an https link to one) and, optionally, which screen it is. It compares it with the board region by region (layout, spacing, colours, type, copy, imagery) and answers with a score, what matches, and each difference: what the design expects, what the build shows, how much it matters and the fix. Run it after each pass until the differences that matter are gone.

3. Plan the build in Margin#

plan_from_board makes a board for the build: a card per screen with its picture attached and its acceptance criteria as the card's checklist, a note holding the brief and the spec, and the open questions as a checklist assigned to the designer. Every card links back to the elements it came from. Run it again after the design changes and the same board and cards are updated, not duplicated; ticked items stay ticked.

Questions back to the designer#

post_design_questions writes the open questions onto the whiteboard itself, in a column beside the drawing, where she sees them and answers by writing next to each one. Nothing she drew moves. The next spec reads her answers.

Specs are versioned: each one names the board version it was read from, so a build can say which version of the design it matches.

What your plan includes#

• Drawing a board at any size, its original pictures and its annotation map: every plan.
• Design Read (the written brief, and posting questions): every paid plan.
• Build specs, checking a build and planning it: Team. Handing a design from the person who drew it to whoever builds it is work between people, which is what Team is for.