How to use the Rig Bundles and Shareable Artifacts agent skill

What the skill makes the agent do

A rig bundle is a packaged artifact that can instantiate an opinionated OpenRig topology and workflow. It can include rig specs, agent specs, workflow specs, startup files, skills or skill references, operating-mode declarations, proof expectations and supporting fragments.

Once the skill is installed, the agent knows to inspect a bundle before installing it, to keep bundles (topology and workflow) separate from extensions (added runtime behavior), and to check that a bundle works on a clean OpenRig environment rather than only on the author's machine. The skill is guidance for the agent. It does not do the work by itself, so the OpenRig CLI must be installed for the commands to run.

• Authoring a bundle from a proven lab pattern
• Installing a bundle with rig bundle install
• Inspecting a bundle before install with rig bundle inspect
• Auditing a bundle for portability
• Deciding whether something belongs in a bundle or an extension

Install the skill from a ZIP file

Download the ZIP for this skill from this page. The skill ships as a single file, SKILL.md. Unzip it so the skill folder sits inside one of these locations: ~/.claude/skills/ for all your projects, or .claude/skills/ inside a specific project folder for that project only.

If you use the Claude apps instead of Claude Code, upload the ZIP under Settings → Capabilities → Skills.

• Personal install: unzip into ~/.claude/skills/
• Project install: unzip into .claude/skills/ in the project root
• Claude apps: Settings → Capabilities → Skills, then upload the ZIP

Know what you need before you start

The skill only applies to OpenRig. It relies on the OpenRig CLI and its rig bundle commands: create, inspect, install and check. If you do not have OpenRig installed, the guidance has no tool to act on, so install OpenRig first.

The skill does not run scripts and does not make network requests, according to its listing. It is written guidance that the agent follows while it uses the OpenRig CLI on your machine.

• OpenRig CLI with rig bundle create, inspect, install and check
• Runs scripts: no
• Uses network: no

Trigger the skill with natural requests

You do not need to name the skill. Describe the task in plain words and the agent should pick it up when the request matches the skill's scope. Good triggers mention bundles, sharing, installing a team setup, or checking portability.

Be specific about the direction of the work. Say whether you are packaging something you built, reviewing something someone else made, or checking an existing bundle.

• Help me package this OpenRig team as a bundle other people can install.
• Before I install this rig bundle, show me what it will create.
• Check whether this bundle will work on a clean OpenRig machine.
• Is this setup a bundle or an extension? It adds a custom dashboard.
• Audit this bundle for missing proof expectations or hidden local paths.

Inspect a bundle before you install it

The skill enforces an inspect-before-install habit. Run rig bundle inspect on the bundle path first. According to the skill, inspect shows what will be created without side effects, so you can read the plan before anything changes on your machine.

Then install with rig bundle install on the same path. Ask the agent to compare the inspect output with what the bundle's documentation promises.

Prepare an exported team for sharing

Running rig export on a team writes the spec file only, not a README, so the exported folder has no documentation of its own. Before you bundle or submit it, add a README.md to the folder and declare it in rig.yaml under docs. Then run rig bundle check on the folder and keep fixing until it reports no findings.

The openrig.dev/rigs registry runs the same check on the folder at the submitted ref, and any finding fails the submission. The full walk-through is the publishing guide, publishing-a-rig-bundle.md, found in $OPENRIG_HOME/reference/.

• Add README.md to the folder
• Declare it in rig.yaml as docs: [{ path: README.md }]
• Run the check until it reports no findings

Avoid the four common failure modes

The skill lists four reasons a bundle works only for its author. Check each one during an audit.

First, paths, providers or credentials are implicit, so the bundle only runs on the operator's machine. Second, the bundle carries too much local state and becomes a backup rather than a reusable artifact. Third, the bundle declares topology but leaves out proof expectations or the workflow mode, so nobody knows what working as advertised means. Fourth, users cannot see what the bundle will create before installing it.

• Implicit paths, providers or credentials
• Local state copied into the bundle
• Missing proof expectations or workflow mode
• No way to inspect what will be created before install