Change several repositories without carrying every handoff yourself.
A shared change touches an API, a desktop app and a website. Give Bellfly the goal and the boundaries for each repository so your agents can work in the right order.
The difficult part is often between repositories.
Which version should the app use? Has the API changed yet? Which tests still need to run? You end up carrying those answers between agents.
What you give Bellfly
The shared design, the repositories involved, their permitted changes, dependency order and the tests each must pass.
Download a task briefBellfly organizes. Your agents get to work.
Once the goal and limits are clear, each next step does not have to wait for you.
Bellfly reads the shared requirements and identifies which changes depend on others.
Your agents work in the permitted repositories, using the agreed versions for each handoff.
Each repository gets its own tests, fixes and review; Bellfly keeps the combined progress visible.
Step away while the work proceeds; return to separate changes and a shared delivery summary.
One repository is blocked.
A dependency may fail its tests or need a decision before a consumer can continue.
How Bellfly continues
Bellfly keeps the completed changes, pauses dependent work and explains the blocked handoff. Unrelated work can remain available for review.
Separate changes that make sense together.
A reviewed change for each repository, the versions used between them, test results and an explicit list of remaining work.
What you still decide
You decide access and release permissions for each repository. Permission in one does not grant permission in another.
Built with Bellfly
We use Bellfly on our own work first.
Software development is where we first put Bellfly to work in depth: the work OrbiFabric does every day. A task can start with a goal and a design, pass through agent implementation, tests, findings, repairs and a Pull Request, and finish with a review. Many of Bellfly’s decisions grew out of that work.