Guide changes to OpenRig itself by locating relevant source files, choosing tests, assessing sensitive areas, and preparing pull requests. Use isolated test environments to check changes without disrupting the daemon running the current agent session.
Use when changing OpenRig's own source in a clone of the openrig repository: finding which package or file owns a behaviour, choosing which tests to run, testing a change without disturbing the OpenRig daemon your own session runs on, judging whether a diff touches a high-risk area, or preparing a pull request. Not for operating rigs (openrig-skills) or designing rig topologies.
Review the instructions the agent will receive before you install.
This skill is a map to the other maps. Each one is incomplete and may be stale: where a map and the code disagree, the code is right, and fixing the map is a welcome contribution.
If you are an agent running inside OpenRig, two different OpenRigs are in play:
rig --version and rig daemon status describe it.git rev-parse HEAD describes it.Restarting the installed daemon does not run your checkout, and stopping it stops the agents running on it, including you. Test your change with the repo's own harnesses, which start a private daemon and tmux server (see "Test it" below), not by restarting the daemon you live in.
| You want to know | Read | How much to trust it |
|---|---|---|
| What OpenRig can already do, before you decide something is missing | rig context get onboarding-width/public-what-you-can-do.md; in this checkout, packages/daemon/context-packs-src/onboarding-width/public-what-you-can-do.md (the installed copy can differ) | The capability map; check it before proposing a new command or calling a gap a defect |
Whether a rig command already exists | rig --help: the full command list, before you decide a command is missing | The running binary; read the whole list, not only the command you expected |
| Whether a problem is already known | The "Known problems to compare against" section of docs/reference/help.md | Lists known issues by symptom; check an issue's current status before relying on it |
| Whether a feature is already planned | ROADMAP.md | Check it before proposing a feature |
| How the packages fit, the request path, where to add a command, route, migration, adapter, skill, context pack or scenario | ARCHITECTURE.md | Checked against the commit it names; counts come with the command to refresh them |
| Whether your change touches a high-risk area, what depends on it, what broke there before | docs/as-built/arteries.md | Incomplete by design: absence from it doesn't make a change safe |
| What to run before you push, and what each layer can and can't prove | docs/as-built/test-layers.md | Checked against the commit it names |
The exact behaviour of a rig command | rig <command> --help on the running binary, then packages/cli/src/commands/ | The binary and the code win over any document |
| A subsystem in depth | docs/as-built/ | Each module names the commit it was last checked against in last-verified-against-source; compare that marker with git log before relying on it |
| Rig spec, agent spec and other user-facing reference | docs/reference/ | Ships to every user; if you find drift, fix it there |
| Which shipped skill covers a task | skills/_canonical/core/openrig-skills/SKILL.md | The index of the skills that ship with OpenRig |
| How to open a good pull request, and what review looks like | CONTRIBUTING.md | Current |
If none of these answers your question, search the code before inventing an answer. A missing map is worth an issue.
If your diff touches anything in arteries.md (message delivery, launch and resume, the queue, rig identity, skill
projection, process observation, migrations, restore):
The short version is npm run build, npm run lint, npm test. test-layers.md has the full ladder, including the
stub-agent scenarios, which run the real CLI, daemon, tmux and SQLite with scripted agents and no model cost.
TMUX and daemon variables, so
it won't touch the daemon your session runs on.OpenRig is a coordination layer for a trusted environment: it should help agents and people keep work flowing.
agent-operated-workflows skill, which ships in the
openrig-core plugin (packages/daemon/assets/plugins/openrig-core/skills/agent-operated-workflows/SKILL.md).Fix it in the same pull request, or open an issue. Update a document's last-verified-against-source marker only when
you have actually checked it against that commit.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Automate website interactions through a command-line browser tool. Navigate pages, fill forms, extract text, save screenshots or PDFs, reuse login sessions, and compare page states to check the effects of actions or website changes.
Design and maintain applications where OpenRig agents help run the system. Organize instructions, shared state, and artifact checks, then trace unexpected behavior to the code, skill, or schema that needs repair.
Design and run bounded procedures in environments where current conditions are uncertain. The skill separates agent judgment from precise tool actions, verifies each effect, and records checkpoints so interrupted work can resume from observed evidence.
Create reusable starting configurations that combine an agent’s role, startup context, and source history. The skill guides registry entries, checks whether their sources are current, and manages their progression from initial capture to recommendation or retirement.
Guides the design and review of agent startup context, including role files and links to authoritative records. It helps identify stale guidance, missing updates, overloaded startup files, and instructions that lose the purpose of the work.
Configure selected OpenRig command permissions in Claude Code or Codex at the agreed project or user scope. Preserve existing restrictions, verify that settings load and behave as intended, and record additions so they can be removed later.