# One feature, three repos: a walkthrough > Source: > Published: 2026-10-03 13:18:11+00:00 You need to add a currency to invoices. The API has to store and return it, the web app has to show it, and somewhere in between a shared types package describes what an invoice looks like. Three repositories, one change. Why a single agent session across repos matters is covered in [the context problem nobody solved](https://ivar.run/blog/ai-coding-agent-multiple-repos). This post is the practical side: the commands, in order, for one feature that touches all three. Register the three repositories in the hall: ``` ivar repo add api git@github.com:acme/api.gitivar repo add web git@github.com:acme/web.gitivar repo add types git@github.com:acme/types.git ``` Each one lands in ivar.json under repos. That file is the hall's manifest: which repos exist, where they come from, which harnesses and MCP servers every session gets. Nothing is promoted yet, so every repo sits on its default branch, read-only. Create the feature and promote the two repos you know you need: ``` ivar feature create billing-currencyivar feature promote billing-currency apiivar feature promote billing-currency web ``` Promoting a repo cuts a billing-currency branch in it and gives it a worktree the feature can write to. types stays on its default branch as read-only context. Start a session: ``` ivar session start billing-currency ``` One session sees both promoted repos side by side, plus types as read-only. The agent can change the API handler and the web component in the same conversation, and it can read the shared types to see what an invoice looks like today. Halfway through, the agent reports the obvious: the invoice type lives in types, and both the API and the web app import it. The currency field has to go there first, or the other two changes won't compile against each other. You don’t need to stop the session or start over. From another terminal, promote the third repo: ``` ivar feature promote billing-currency types ``` types gets its own billing-currency branch and worktree, and the session can now write to it. The agent adds the field to the shared type and carries on with the API and the web app. The [features guide](https://ivar.run/docs/guide/features) covers promotion in more detail. Check the feature: ``` ivar feature status billing-currency Feature `billing-currency` (branch: billing-currency): api ready worktree present base: main types ready worktree present base: main web ready worktree present base: main ``` Three repos, one branch name, each based on its own main. No list of branches to keep in your head. When the work is done, preview the delivery: ``` ivar feature deliver billing-currency --preview ``` The preview writes nothing. For each promoted repo it reads the branch, the remote, the base and any existing pull request, then computes one fingerprint over all three. If any repo changes after you read the preview, the fingerprint no longer matches and apply refuses. Apply it with the fingerprint the preview printed: ``` ivar feature deliver billing-currency --fingerprint ``` That pushes the billing-currency branch in each repo and opens the three pull requests together, each with a comment linking its siblings, so a reviewer on the web PR can find the API and types PRs. Creating pull requests needs GitHub remotes. With local remotes, delivery only pushes. The [delivery guide](https://ivar.run/docs/guide/delivery) covers updating existing pull requests and delivering a subset of repos with --only. Cloning, branching, cross-linking pull requests and re-explaining context to fresh sessions were all handled by the feature, including when the scope grew mid-way. [One feature, three repos: a walkthrough](https://blog.devgenius.io/one-feature-three-repos-a-walkthrough-f3f3de14701a) 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.