Ship a contributor team with your open-source project

When OpenRig took off, I started adding teams of agents to handle different parts of the work. Over the last three weeks, I've been scaling those teams across additional machines. The onboarding work I'd done months earlier meant new agents could find useful project context and get to work without me explaining everything to each one.

I'd like to help other open-source projects do something similar. An open-source project should be able to ship a team that knows how to work on it.

Someone who wants to contribute could install that team, give it a task, and have it start with the project's conventions, existing systems and working practices already in reach. The maintainer would have a way to share what makes an agent useful on their project.

That's the idea behind rig bundles in OpenRig. A rig is a team of agents with defined roles and ways of working together. A bundle packages that team and the files it needs. It can also carry a project world, which is how I organize the context agents need to find their way around a project.

I've had agents reinvent things we already had. I've also seen people suggest features that already exist. That could be a discoverability problem in my own project, but I suspect a lot of fast-growing projects have some version of it. An agent can be perfectly capable of implementing the feature and still have no idea that it should be looking for an existing one.

When more people start contributing with agents, the maintainer can end up doing that orientation after the code has already been written. Someone has to explain where the change belongs, what it duplicates, or why the project does things a particular way. More code coming in can mean more work for the person reviewing it.

So I'd like to move some of that onboarding to the front of the contribution process.

A team template gives you a builder, a reviewer, maybe a QA agent. They also need to understand the project they're joining. Where are the important systems? Which conventions should they follow? Where do they look when the first thing they find doesn't answer the question?

This is where the project world comes in. In practical terms, it's files, headings and links arranged as a map of the project. I give agents a wide-angle view of what exists, with routes into the detail they'll need for a particular job. They can discover a part of the project before they know enough about it to search for the right implementation.

Let's say someone wants to add a Slack integration. The useful starting point is knowing that the project already has a messaging system. From there, the agent can find how messages are addressed and delivered, and work out where Slack should connect. That changes the problem it's solving before it writes any code.

The map doesn't need to contain every answer. It needs to tell the agent where to look and what to do when it reaches something it doesn't understand. I call the goal minimum viable competence. Enough orientation to do useful work and recognize when more context is needed.

And the maintainer needs to be able to understand that map too. During OpenRig's growth, I found places where new agents were missing routes to important knowledge. Because I could read the same structure they were using, I could trace the missing connections and repair them. That context engineering became something I could maintain as the team grew.

Workshop is a concrete starting point. It's a four-agent contributor team based on the template I use to build OpenRig, with a lead, builder, reviewer and QA agent. The lead scopes the work, the builder implements it, and the other agents review and test it.

The published setup shows an optional step to add OpenRig's own context pack with rig context add, so the agents can find guidance on using OpenRig. You then install the team against your checkout with rig up. The map of your project is the part you'd add. Workshop gives you a team to start from; it doesn't arrive knowing an unfamiliar codebase.

The bundle format also supports carrying the world's files inside the bundle as a context pack. For a GitHub-folder install, that pack has to be declared in the folder's bundle.yaml. Workshop currently uses the separate setup step described above.

You bring the coding harnesses and model access. OpenRig works with Claude Code, Codex and Pi; Pi is the route I'm interested in for open models. The bundle supplies the team configuration and its context, while the agents run using your accounts. Each listing says which configurations have been tested.

What I want to explore next is doing this for other projects. Take a project, build a useful map of it, and package that with a team that can review PRs or work on issues. Give people something they can install and inspect, then learn where the agents still get lost.

I'd start with one useful job, like reviewing a PR. Work out which conventions and prior decisions the reviewers need to find, where the relevant tests live, and what they should bring back to the maintainer. Then try it on real work. Wherever the team gets lost gives you something specific to improve in the project world, and that improvement can go into what you share with the next contributor.

I think that's an interesting next step beyond sharing individual skills. A skill packages guidance for a particular kind of task, and those skills remain useful inside the team. A rig lets us share how the team works together, along with the world it knows how to work in. That's what I mean by a shippable unit of competence.

The team still needs review, and the project world needs maintenance. The thing I want to test is whether giving contributors a project-aware team can improve the work before it reaches the maintainer. OpenRig has been my own stress test; I'd like to see where the approach holds up on other projects.

You can inspect Workshop and its source, adapt it, or use it as a reference for your own team. I also made a video about the context engineering behind this, including how I build the maps and how the agents use them.

If you're maintaining an open-source project and trying to keep up with the work, tell me about it. I'd like to help put together a useful starting team and its project world, then make that available to other people who want to contribute.