DEV Community

Cover image for One repo, many agents: parallel features from a Figma prototype
Gabriel Menezes
Gabriel Menezes

Posted on Edited on Originally published at ivar.run

One repo, many agents: parallel features from a Figma prototype

#ai #git #figma #devtools

One repo, one big prototype

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 many parallel branches, or only when work spans several repositories? It does, and this post walks through it end to end.

The hall with one repo

Create the hall as its own git repo, then add the app repository:

mkdir app-hall && cd app-hall && git init
ivar init
ivar repo add app git@github.com:acme/app.git
Enter fullscreen mode Exit fullscreen mode

ivar init sets the hall up for Claude Code. For OpenCode or OMP, run
ivar init --provider opencode or ivar init --provider omp instead.

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 dependencies and generated code are not there. Put what a new worktree needs in a setup script at .ivar/setups/app.sh:

set -euo pipefail
make deps
make codegen
Enter fullscreen mode Exit fullscreen mode

ivar runs it with bash inside the new worktree, and every branch you cut below runs it, so each agent starts from a working tree instead of a broken build. The setup script guide lists the variables the script gets and has a Flutter version (flutter pub get, build_runner, pod install, secrets).

A main feature and one subfeature per slice

Create the main feature and promote the repo in it first:

ivar feature create figma-proto
ivar feature promote figma-proto app
Enter fullscreen mode Exit fullscreen mode

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 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.

Now add one subfeature per slice and promote the repo in each:

ivar feature create onboarding --parent figma-proto
ivar feature promote onboarding app
ivar feature create checkout --parent figma-proto
ivar feature promote checkout app
ivar feature create profile --parent figma-proto
ivar feature promote profile app
Enter fullscreen mode Exit fullscreen mode

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.

Before the children start, commit anything two of them would both edit on figma-proto: new dependencies in pubspec.yaml or package.json, the route table, theme tokens. Each child then owns its own files, and integration has nothing to conflict on.

One agent per slice

Open a session on the main feature and hand the split to /ivar-subfeatures:

ivar session start figma-proto
Enter fullscreen mode Exit fullscreen mode 
/ivar-subfeatures figma-proto
Enter fullscreen mode Exit fullscreen mode

The skill creates and promotes the children if you have not, then writes each child's plan from its slice of the prototype: the screens it owns, the Figma frame links, the checks to run. It approves those plans and starts one detached session per child. For each child it prints the command that launches your harness in that session; paste each into its own terminal. In each child session, run /ivar-execute.

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.

Watching the tree

From any terminal, look at the whole tree:

ivar feature status figma-proto --recursive
Enter fullscreen mode Exit fullscreen mode

After onboarding and checkout have been folded back, it looks like this:

Subtree:
  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
Enter fullscreen mode Exit fullscreen mode

The main feature lists the children that still block it. Once profile is integrated, nothing does.

Folding slices back

When a child's run finishes, quit its harness so its session ends, then integrate it from the figma-proto session. /ivar-subfeatures does this for you as each child finishes; by hand it is one command:

ivar feature integrate onboarding
Enter fullscreen mode Exit fullscreen mode

Integration requires the child's plan gate to be approved, which the skill did when it wrote the plan. If you skip the skill, write the child's plan before you approve it:

ivar plan create onboarding plan
ivar plan approve onboarding plan
Enter fullscreen mode Exit fullscreen mode

Approving the empty scaffold passes the gate and gives the child's agent nothing to build. The child's work lands on the figma-proto branch and the child closes as integrated. A merge conflict fails the command; fix it on the child's branch and run it again. Repeat for checkout and profile.

One pull request

With every child integrated, the main feature carries all three slices. Preview the delivery first:

ivar feature deliver figma-proto --preview
Enter fullscreen mode Exit fullscreen mode

The 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:

ivar feature deliver figma-proto --fingerprint <fp>
Enter fullscreen mode Exit fullscreen mode

That 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 covers the details, including updating a pull request that already exists.

When you don't need ivar

If 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.

ivar 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.

Related

Top comments (0)