Turn a requirement into a real Figma design — grounded in how your users actually think.
The Requirement-to-Design Agent consumes a discovery brief and a PRD and produces a high-fidelity Figma design in an evolving master file. Every layout decision is anchored to a concrete persona and journey, not a generic UI template — and nothing is written to Figma without an explicit human decision.
What it does
One agent, the full requirement-to-design loop
Every capability below runs through the same reviewed, resumable LangGraph workflow — nothing reaches Figma without a checkpoint.
Persona-grounded design reasoning
Derives a concrete persona and journey — goals, pain points, and design opportunities — from the discovery brief before any screen is drawn, so layout and flow trace back to how that person actually thinks, not generic UI conventions.
A reviewable write plan, not raw pixels
Compiles the PRD into an explicit Figma write plan — frames, components, states, prototype connections, one-sentence rationale per operation — that a person can read and approve before it touches a design file.
Human-operator handoff via Figma MCP
The agent itself never calls the Figma API. It hands the write plan to whoever holds Figma's official MCP plugin, who executes it and confirms the write-back before the workflow continues.
One evolving master file
A persisted master-file identity in Postgres means the second and third designs for a project build onto the same canvas the first run created — not a pile of disconnected one-off Figma files.
Self-learning from every review
Approved and rejected write plans, plus the persona journeys behind them, are embedded and stored, so future runs draw on your own team's real feedback and design patterns — not just a cold-start guess.
Resumable by construction
Built on LangGraph with a Postgres checkpointer — a run can pause at a review gate for minutes or days and resume from exactly that point after a restart, without losing persona or write-plan state.
How it works
A resumable, reviewed workflow — not a one-shot generation
Built on LangGraph. Every run can pause at a checkpoint and resume exactly where it left off, days later if needed.
Resolve the master file
Checks for an existing design master file for this project in Postgres — reuses it, or bootstraps a new one — so every future run has a stable Figma identity to build onto.
Establish the persona
Grounds the whole design in a concrete persona and journey derived from the Stage 1 discovery brief — how this person thinks and moves through the product, not a generic archetype.
Compose the Figma write plan
Turns the PRD and persona journey into an explicit set of Figma operations — frames, components, states, and prototype connections — each with a short rationale.
Checkpoint ① — you review the write planHuman operator executes it
Whoever holds Figma's official MCP plugin runs the approved write plan against the master file and reports back what was actually created.
Checkpoint ② — you confirm the write-backLearn from the outcome
The approved plan, any rejection feedback, and the persona journey behind them are embedded into Qdrant, so the next run for this project — or the next project entirely — starts from real prior decisions.
The HMHT framework
"How Might Human Think" — persona reasoning wired into the graph, not bolted on after
HMHT is a discipline enforced by three LangGraph nodes: a persona and journey are derived from the discovery brief first, then every write-plan decision is required to reference them.
Derive the persona
Builds a concrete Persona and PersonaJourney from the discovery brief — goals, pain points, and the design opportunities they imply.
Compile it into context
Turns the persona and journey, including its opportunities, into a context block every downstream node must read before proposing anything.
Ground every operation
Each frame, component, and connection in the write plan carries a one-sentence rationale tied back to that specific persona's journey.
With HMHT
- Flow and layout choices trace back to a named persona's goals and pain points, not a generic template for the feature type.
- Design opportunities the journey surfaces are explicit and available to shape the write plan, not left implicit.
- The persona and journey persist in the master file's history, so the next screen or the next run starts from the same grounded context.
- Write-plan rationale says who a layout serves and why, which gives the review checkpoint something concrete to accept or challenge.
Without HMHT
- The agent defaults to conventional patterns for the stated feature set — competent, but generic.
- No persona or journey artifact exists to review, question, or refine.
- Each run starts cold — nothing persona-specific carries forward to the next screen or project.
- Rationale, where it exists, describes what a screen does — not who it's for.
Figma MCP integration
Writes designs the same way a person would — through Figma's own MCP tools
This agent runs in reverse from a typical design-to-code tool: it starts from text (a discovery brief and a PRD) and produces a structured plan for creating Figma content. It never authenticates to the Figma API itself. The plan is handed to whichever MCP client already has Figma's official plugin connected, and that plugin's own write tools execute every frame, component, and prototype connection.
- Agent composes a
FigmaWritePlan— an ordered list of create/update operations with a one-sentence rationale each - Workflow pauses at
review_write_plan— you approve, or send back specific feedback for a revision - Workflow pauses again at
await_figma_writeback— the operator runs the plan viause_figmaand other official plugin tools - Operator reports back what was created; the agent records the outcome and the master file's new state
Requirements
What you need to run it
| Component | Notes | |
|---|---|---|
Python 3.11+ and uv | Runs the agent server (FastAPI + LangGraph) | Required |
| An MCP-compatible client | Claude Code, Claude Desktop, or any Model Context Protocol client | Required |
| An LLM provider | Claude, Gemini, or any LiteLLM-supported provider — a single config value switches providers | Required |
| Figma's official MCP plugin | Held by the human operator who executes each approved write plan against the master file | Required |
| A Stage 1 discovery brief + Stage 2 PRD | The starting input this agent grounds every persona and screen in | Required |
| PostgreSQL | Master-file identity, checkpointed interrupts that survive a restart, run history | Recommended |
| Qdrant | Self-learning layer — embeds approved plans, feedback, and persona journeys for future runs | Optional |
Data & privacy
How your design data is handled
This agent is self-hosted by your organization — it is not a hosted third-party service, and it does not sell or share data.
Self-hosted, org-controlled
Runs entirely on infrastructure your organization controls. Discovery briefs, PRDs, write plans, and run history stay on your own servers and database.
You choose the LLM provider
Discovery-brief and PRD text is sent only to the LLM provider you configure (e.g. Anthropic, Google, or a self-hosted model) — never to any other third party.
No Figma credentials held by the agent
Every write plan executes through the human operator's own authorized Figma MCP session — this agent never stores or uses a Figma token itself.
Nothing ships without a decision
Both the write plan and the write-back confirmation are explicit LangGraph interrupts — a rejected plan is revised from your literal feedback, never silently retried.
Get started
Add the MCP server to Claude Code or Claude Desktop, then hand it a discovery brief and a PRD.
Claude Code (CLI)
Claude Desktop (or manual .claude/settings.json)