What is a rig?

A rig is a folder. Inside it: system prompts, MCP server configs, tool requirements, allow/deny rules for your agent, the data the agent reads from, and instructions for setting it all up.

You can pack a rig into a single .rig.tgz artifact, publish it, and let anyone else install it with one command. They'll get the same workspace you have — minus your secrets and private data.

What it solves

If you've ever tried to share an agent workspace, you've hit these:

• "What MCP servers do I need to install?"
• "Which env vars does this expect?"
• "What permissions did you grant Claude?"
• "Wait, that file isn't in the repo, can you send it?"

Rig answers all of these declaratively in a single rig.toml file at the root of the workspace. The CLI inspects that file, sets up what can be set up automatically, and asks for the rest. An agent like Claude Code running inside the workspace reads it too — via rig doctor --json — and can self-heal gaps without a human in the loop.

What it isn't

• Not a package manager. Rig doesn't try to solve a dependency graph; agent workspaces don't have one. It's a system of record + state observer. See Concepts.
• Not a runtime. Rig doesn't run your agent. You install a rig, then cd in and start claude (or whatever runtime the rig declares).
• Not an executor. Rig won't silently install MCP servers, run shell hooks, or grant permissions. It tells you (and the agent) what's missing; it doesn't fix things behind your back.

Two flavours

Solo rigs — what most published rigs are. You install it, you run it, your files stay on your machine. Workflows: install, build, publish.

Shared rigs — opt-in collaboration. You and a teammate are working on the same rig together; edits sync in real time across machines. The owner runs rig share <teammate-email> — which enables [sync], goes live, and mints an invite in one step. Workflow: Collaborate.

Next

• New here? Install the CLI.
• Already installed? Either install a rig or create one.
• Want the mental model? Read Concepts.