One feature, three repos: a walkthrough Ivar, a tool for running AI coding agent sessions across multiple repositories, published a walkthrough showing how one feature touching three repos — api, web, and types — can be handled in a single session using commands like `ivar repo add`, `ivar feature promote`, and `ivar feature deliver`. The walkthrough demonstrates promoting a third repo mid-session without restarting, and delivering all three pull requests together using a fingerprint that refuses to apply if any repo changes after the preview. The tool requires GitHub remotes to open pull requests; with local remotes, delivery only pushes. 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