{"slug": "one-repo-many-agents-parallel-features-from-a-figma-prototype", "title": "One repo, many agents: parallel features from a Figma prototype", "summary": "Ivar, a tool for running multiple coding agents in parallel, published a walkthrough showing how three agents can build onboarding, checkout and profile features from a single Figma prototype in one app repository and deliver the work as a single pull request. The workflow uses `ivar init`, `ivar repo add`, a Figma MCP server declared once in ivar.json, a setup script at .ivar/setups/app.sh, and one subfeature per slice created with `ivar feature create <name> --parent figma-proto` and promoted with `ivar feature promote`, each running in its own worktree and session. Each slice is integrated into the parent feature via `ivar plan create`, `ivar plan approve` and `ivar feature integrate`, after which `ivar feature deliver figma-proto --preview` prints a fingerprint without writing anything.", "body_md": "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.\n\nDoes 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.\n\nStart a hall and add the repository:\n\n```\nivar initivar repo add app git@github.com:acme/app.git\n```\n\nThe 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](https://ivar.run/blog/figma-mcp-opencode) shows the block and the auth step, and the [MCP guide](https://ivar.run/docs/guide/mcp) covers the other harnesses.\n\nA 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:\n\n``` bash\n#!/bin/shset -emake depsmake codegen\n```\n\nEvery branch you cut below runs it, so each agent starts from a working tree instead of a broken build.\n\nCreate the main feature and promote the repo in it first:\n\n```\nivar feature create figma-protoivar feature promote figma-proto app\n```\n\nOrder 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 asks to promote the parent for you, and without a terminal it refuses with the exact ivar feature promote command to run — it never cuts the child from main behind your back.\n\nNow add one subfeature per slice and promote the repo in each:\n\n```\nivar feature create onboarding --parent figma-protoivar feature promote onboarding appivar feature create checkout --parent figma-protoivar feature promote checkout appivar feature create profile --parent figma-protoivar feature promote profile app\n```\n\nEach child has its own branch and worktree, based on figma-proto. The [Subfeatures section of the features guide](https://ivar.run/docs/guide/features#subfeatures) is the short reference for this flow.\n\nOpen a terminal per slice and start a session in each:\n\n```\nivar session start onboarding\n```\n\nThen 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.\n\nEach 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.\n\nFrom any terminal, look at the whole tree:\n\n```\nivar feature status figma-proto --recursive\n```\n\nAfter onboarding and checkout have been folded back, it looks like this:\n\n```\nSubtree:  figma-proto  state active  repos 1  blocked by: profile (active)    checkout  state integrated  repos 1    onboarding  state integrated  repos 1    profile  state active  repos 1\n```\n\nThe main feature lists the children that still block it. Once profile is integrated, nothing does.\n\nWhen 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:\n\n```\nivar plan create onboarding planivar plan approve onboarding planivar feature integrate onboarding\n```\n\nThe child’s work lands on the figma-proto branch and the child closes as integrated. If a slice deserves a written plan with requirements first, the [planning guide](https://ivar.run/docs/guide/planning) covers the full flow. Repeat for checkout and profile.\n\nWith every child integrated, the main feature carries all three slices. Preview the delivery first:\n\n```\nivar feature deliver figma-proto --preview\n```\n\nThe preview writes nothing. It reads the branch, the remote, the base and any existing pull request, and prints a fingerprint. When it looks right, apply it with the fingerprint the preview printed:\n\n```\nivar feature deliver figma-proto --fingerprint <fp>\n```\n\nThat pushes the figma-proto branch and opens one pull request against main. Creating the pull request needs a GitHub remote; with a local remote, delivery only pushes. The [delivery guide](https://ivar.run/docs/guide/delivery) covers the details, including updating a pull request that already exists.\n\nIf you use one harness on one repo and never run work in parallel, you may not need any of this. Commit an .mcp.json with the Figma server, use git worktree add when you want a second branch checked out, and move on.\n\nivar starts paying off when several agents run at once, possibly in different harnesses, and each needs the same MCP servers, the same setup script and an isolated worktree, with a way to fold the pieces back into one change.\n\n[One repo, many agents: parallel features from a Figma prototype](https://blog.devgenius.io/one-repo-many-agents-parallel-features-from-a-figma-prototype-5bcaf2e9910f) was originally published in [Dev Genius](https://blog.devgenius.io) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/one-repo-many-agents-parallel-features-from-a-figma-prototype", "canonical_source": "https://blog.devgenius.io/one-repo-many-agents-parallel-features-from-a-figma-prototype-5bcaf2e9910f?source=rss----4e2c1156667e---4", "published_at": "2026-10-03 13:18:13+00:00", "updated_at": "2026-10-03 13:38:55.642230+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools", "agent-protocols"], "entities": ["Ivar", "Figma", "OpenCode", "GitHub", "Model Context Protocol"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/one-repo-many-agents-parallel-features-from-a-figma-prototype", "markdown": "https://wpnews.pro/news/one-repo-many-agents-parallel-features-from-a-figma-prototype.md", "text": "https://wpnews.pro/news/one-repo-many-agents-parallel-features-from-a-figma-prototype.txt", "jsonld": "https://wpnews.pro/news/one-repo-many-agents-parallel-features-from-a-figma-prototype.jsonld"}}