design-to-code pages
- design-to-code
- 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.
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
d2ccommand that runs from any folder (design-to-code#8). You would rund2cin a folder that holds a design export, and a project would commit itsprojects/<slug>.jsonbeside its own code, so CI can rund2c gates --localthere. Other tools would import the verbs as functions. - An extraction plan for rafa (design-to-code#16). After
seed, a plannedd2c plan --format=rafawould print a rafa plan from the seed manifest.rafa loop startwith 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.jsonto 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 isimport,assess,serveandgates;baselineandseedcome 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, ornone), 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-checkwould run the visual gates inside a Grow Box sandbox sized for browser work, through the plannedrafa-sandboxadd-on (rafa#1261).--freshwould 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
| Step | Planned piece |
|---|---|
| One person | import a design export and seed components on request, through rafa |
| A project building UI with loops | the skill that makes every UI task name its reference and gates |
| A team setting up a new machine | sandbox-check --fresh |