OpenRig

Rigs

Install a team someone already debugged.

Teams of agents you can install by pasting one block. Each one shows what it will do and how much OpenRig has tested it, for the harnesses you have.

Contributing to someone else's project? Install a team that learns its conventions first, so the pull request you send reads like the maintainers' own.

  • Every seat is a real Claude Code, Codex or Pi session, no wrapper
  • Pinned to a commit
  • Shows what it will do before it starts
  • Reviewed for listing, not a security audit

Picked by OpenRig maintainers as the best place to start. Each seat runs in a harness, the agent app you already use: Claude Code, Codex or Pi. What the labels mean

Workshop

Listed by OpenRig maintainers · 4 seats · runs on Claude Code, Codex or Pi

One four-seat software team: a Codex lead and reviewer, Claude Code builder and QA by default. The installing agent selects available runtimes while keeping the workshop name and one install directory.

  • Not tested by OpenRig

Permission prompts: off

Reviewed for listing · not a security audit

  • Recommended
  • All Claude
  • All Codex
  • All Pi
See the team and install →

Reference teams

Larger teams OpenRig keeps as worked examples. Install them the same way; they're not tested by OpenRig unless the label says so.

Community listings

Teams other people built and submitted. Each one is reviewed and pinned to a commit before it appears here. What the labels mean

No community listings yet.

Share your team and it can be the first.

What the labels mean

Every team shows two things before you install it: how much OpenRig has tested it, and whether its agents ask before they act. Both are per harness setup, so they can change when you pick different harnesses.

How much OpenRig has tested it

From OpenRig's own test runs, recorded for each harness setup and platform.

Tested by OpenRig
OpenRig ran it, and nobody had to step in.
Tested with help (N)
It worked, but someone had to step in N times to get it there.
Partly tested
Only part of it was run. A note on the team's page says what was skipped.
Known problem
It fails in a way OpenRig has seen. The note says how.
Not tested by OpenRig
No run is recorded for this setup yet. That's not a failure, just no evidence either way.
Status unavailable
OpenRig's records for this setup couldn't be read, or are missing.

What counts as help. An assist is one action a person or the test runner took to get past a problem during the run, such as restarting a seat or re-running a command; following the bundle's own documented steps doesn't count.

Community reports from people who ran a team appear beside the label and never change it. No label is green: each one says what happened, not that a team is safe.

Permission prompts

Declared by the team's author for each seat, and shown before you install.

On
Each agent asks you before it runs a command or changes a file.
Off
The agents act without asking you first: they run commands and change files on their own. The first time on a machine, Claude Code asks once to accept this.
Your machine's default
OpenRig asks before acting unless your own settings turn prompts off.
Policy <name>
A named rule set that allows some actions and asks about others. The team's page links to what it allows.
Not stated by the bundle
The team doesn't say. Pi seats always show this, since the bundle can't tell which Pi you run.

Before you install a team with prompts off, read what it will do on its page: which agents start, what they're told, what they write and which addresses they mention. Agents run as you, with your access.

To report a problem with a team, use "Tell us how it went" on its page. A withdrawn team's page says so, with the date, and no longer offers an install command. When seats differ, the page lists them, for example "off for dev.build; on for the other seats". Every listing is reviewed before it appears. Review is not a security audit.

Share your team

Publish your team on GitHub and submit the link. After review it appears here automatically. Your files stay in your repository; the listing records the exact commit a maintainer reviewed. You get your name and repository on the listing, a page at openrig.dev/rigs/your-team, and a badge for your README.

  1. Step 1

    Put the team on GitHub

    A folder with rig.yaml, configurations.yaml (which harness each seat can use) and bundle.yaml (what people need before they install). Check what each configuration will do before you submit.

    # the workshop's own output
    $ rig bundle configurations rig.yaml
    recommended: dev.build=claude-code,dev.qa=claude-code,dev.review=codex,orch.lead=codex  (recommended, as rig.yaml is written)
    all-claude: dev.build=claude-code,dev.qa=claude-code,dev.review=claude-code,orch.lead=claude-code
    all-codex: dev.build=codex,dev.qa=codex,dev.review=codex,orch.lead=codex
    all-pi: dev.build=pi,dev.qa=pi,dev.review=pi,orch.lead=pi
    $ rig bundle check .
  2. Step 2

    Submit the link

    Open a pull request on mvschwarz/openrig-world that adds one small file. The registry check replies "Submission received", or tells you the name is taken.

    # registry/submissions/your-team.yaml
    repository: https://github.com/you/your-repo
    folder: rigs/your-team
    ref: main
  3. Step 3

    Reviewed, pinned, listed

    A maintainer pins your ref to a full commit, generates what each configuration will do, and lists it. A later push changes nothing here until an update is reviewed.

    ✓ Listed: openrig.dev/rigs/your-team
    Badge: [![Listed on OpenRig](https://openrig.dev/rigs/your-team/badge.svg)](https://openrig.dev/rigs/your-team)
    Reviewed for listing on <date> at commit <short>. Review is not a security audit.

    Workshop: listed on OpenRig The Workshop team's badge