Skip to content
open tomato/ design-to-code
GitHub
design-to-code pages
  1. design-to-code
  2. With rafa

With rafa

What is planned to connect design-to-code to rafa, from a d2c command run in any folder to a rafa add-on with its own UI skill.

NOTE

This page is a placeholder: everything on it is planned in open specs, and none of it is built. It names no dates, because the specs name none.

Today

design-to-code runs on its own, from its repository root, with bun run d2c <verb>. It does not need rafa, and rafa does not call it.

Coming in design-to-code

These are open specs on design-to-code's own board.

  • A d2c command that runs from any folder (design-to-code#8). You would run d2c in a folder that holds a design export, and a project would commit its projects/<slug>.json beside its own code, so CI can run d2c gates --local there. Other tools would import the verbs as functions.
  • An extraction plan for rafa (design-to-code#16). After seed, a planned d2c plan --format=rafa would print a rafa plan from the seed manifest. rafa loop start with that plan would then build one component per session, in the manifest's order.
  • Import from Claude Design's "Send to Claude" (design-to-code#19). The tool would print a prompt for the designer to paste, and finish on its own once the files arrive.
  • A library manifest (design-to-code#20). An app repository that links an extracted library would read d2c-library.json to see which export revision it came from and how its gates went.

Coming in rafa: the rafa-d2c add-on

rafa's repository plans an addons/ folder for modules rafa does not bundle (rafa#1257, add-ons in their own folder). Each add-on is published on its own, and a project loads it by a path until rafa can install add-ons from npm. design-to-code stays its own repository; the add-on is the bridge.

rafa-d2c (rafa#1262, design-to-code as a rafa mode) is planned to bring three things:

  • Verbs on request. rafa module exec rafa-d2c <verb> would call design-to-code's verb in the project and exit with its code. The first step is import, assess, serve and gates; baseline and seed come in a second step.
  • A UI skill, ui-reference-gates, for the planner and the other roles in a loop. Every UI task would name what it is checked against (a library story, a design frame, or none), and the gates would follow from that, so a loop cannot finish UI that is right in code and wrong on screen.
  • A visual check in a sandbox. sandbox-check would run the visual gates inside a Grow Box sandbox sized for browser work, through the planned rafa-sandbox add-on (rafa#1261). --fresh would build a new box and remove it after, which proves a new machine can run the visual pipeline from nothing.

Who each piece is for

StepPlanned piece
One personimport a design export and seed components on request, through rafa
A project building UI with loopsthe skill that makes every UI task name its reference and gates
A team setting up a new machinesandbox-check --fresh