TL;DR — An internal CLI tool that takes a Figma frame and a backend codebase and generates a doc for the backend engineer: what data models and endpoints the design needs, what already exists, and what decisions to settle before coding.
What it is
Backend work sits at the end of the line. A design lands, and you still have to figure out what's new, what already exists in the schema, and what's ambiguous before you can start. blueprint2backend does that first pass for you.
Give it a Figma frame and a backend repo (GitHub URL or local path). A short chain of agents picks the relevant files, maps the existing schema, reads the design, and synthesizes the difference. Out comes one markdown doc with:
- a read of your codebase (language, framework, ORM, conventions),
- a Mermaid ERD with
%% NEWmarks on what the design implies, - a "What's new" table of entities, fields, relations, and endpoints,
- a "Decisions to make" list: the open questions, each with options and what they block.
The point is to review a diagram and a spec instead of a screen, and to surface the hard or ambiguous parts early enough to take back to product.
Demo
One sharing feature, design in and doc out.
Point it at that frame and the backend repo, and the report comes back. First the diagram, with %% NEW marks on everything the design implies:
A "What's new" breakdown of every new entity, field, and relation, each with the reason it exists:
And the new endpoints, plus the open questions to settle before any code gets written:
From that design it inferred a Share and ShareOption table, five new endpoints, turned the UI's error states into status/error fields, and flagged "what's actually being shared" as a decision to settle instead of guessing.
Usage
d2d \
--figma "https://figma.com/design/FILE_KEY/...?node-id=1-23" \
--repo "https://github.com/org/repo" \
--output diagram.md
Single run, no persistent state. More real outputs are in runs/.
Note: written with the help of an llm from my project + own points, dont mind the llm-ish words :>