One repo, many agents: parallel features from a Figma prototype
One repo, one big prototype
Spots 
Your designer hands over a Figma prototype with
Your designer hands over a Figma prototype with onboarding, checkout and a profile area. It all lands in one app repository. You want three agents working at once, one per area, and you want the result to arrive as a single pull request.
Does ivar make sense with one repo and
Does ivar make sense with one repo and many parallel branches, or only when work spans several repositories? It does, and this post walks through it end to end. Start a hall and add the repository:
The Figma MCP server is declared once in
The Figma MCP server is declared once in ivar.json and materialised into each session, so every agent you start can read the prototype. Configure Figma MCP for OpenCode in one step shows the block and the auth step, and the MCP guide covers the other harnesses.
A fresh worktree is a clean checkout. Installed
A fresh worktree is a clean checkout. Installed dependencies and generated code are not there. Put what a new worktree needs in a setup script at .ivar/setups/app.sh: Every branch you cut below runs it, so each agent starts from a working tree instead of a broken build. A main feature and one subfeature per slice Create the main feature and promote the repo in it first:
Order matters. A subfeature's branch is cut from
Order matters. A subfeature's branch is cut from its parent's branch, and that branch only exists once the parent has promoted the repo. If you promote a child first, ivar warns that the declared base does not exist and cuts the child from main instead. Now add one subfeature per slice and promote the repo in each:
Each child has its own branch and worktree
Each child has its own branch and worktree, based on figma-proto. The Subfeatures section of the features guide is the short reference for this flow. Open a terminal per slice and start a session in each:
Then ivar session start checkout in the second
Then ivar session start checkout in the second terminal and ivar session start profile in the third. There is no single command that starts all three; you open them yourself, one per terminal.
Each session works in its own worktree, so
Each session works in its own worktree, so the agents never touch each other's files, index or HEAD. Each session also gets the same harness config and the same MCP servers, Figma included. You point each agent at its frame in the prototype and let it build. From any terminal, look at the whole tree: After onboarding and checkout have been folded back, it looks like this: The main feature lists the children that still block it. Once profile is integrated, nothing does.
When a slice is done, integrate it into
When a slice is done, integrate it into its parent. Integration requires the child's plan gate to be approved. For a small slice, the plan alone is enough:
News
One repo, many agents: parallel features from a Figma prototype
One repo, one big prototype
@spots #dev
Source: Dev.to