Skip to content
cccskills
FreePublished on GitHub

rig-bundles-and-shareable-artifacts

Package an OpenRig agent arrangement and workflow for reuse by others. Guides bundle creation, inspection before installation, and checks in a clean environment to identify hidden dependencies on local paths, providers, or credentials.

OriginalShow the original description

Use when authoring or installing a rig bundle (packaged, shareable artifact that instantiates an opinionated OpenRig topology + workflow), reasoning about the bundle vs extension boundary, or auditing a bundle for portability. Covers the 4 failure modes that prevent bundles from working anywhere but the operator's machine, and the inspect-before-install discipline.

See how to install

Good for

  • Package a proven agent setup for reuse
  • Inspect bundle contents before installation
  • Check whether a bundle works in a clean environment
  • Decide whether to use a bundle or an extension

Files included (1)

  • SKILL.md4.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Rig Bundles and Shareable Artifacts

A rig bundle is a packaged, shareable artifact that can instantiate an opinionated OpenRig topology and workflow. It may include:

  • rig specs
  • agent specs
  • workflow specs
  • startup files
  • skills or skill references
  • operating-mode declarations
  • proof expectations
  • supporting fragments

Shareable artifact is broader than bundle: specs, bundles, skills, workflows, and extensions can all be shared. A bundle is the packaged form for "load this topology and way of working."

Use this when

  • Authoring a bundle from a proven lab pattern
  • Installing a bundle (rig bundle install <path>)
  • Inspecting a bundle before install (rig bundle inspect <path>)
  • Reasoning about bundle vs extension boundary (bundle declares topology + workflow; extension adds behavior)
  • Auditing a bundle for portability — does it work on a clean OpenRig environment, or only the author's machine?

Don't use this when

  • The work is a one-off topology you won't reuse. Specs alone are sufficient.
  • The intent is to add runtime behavior (commands, views, dashboards). Use extension-and-user-workspace, not bundles.
  • You want to ship a workflow as a daemon feature. Bundle is the path before daemon promotion.

The bundle vs extension boundary (load-bearing)

ConceptDeclaresExample
BundleRig shape + workflow ("load this topology and way of working")A Velocity Team bundle
ExtensionBehavior added to user workspace/runtimeA custom command, view, or dashboard

Don't confuse them. A bundle is opinionated content; an extension is added behavior. Both can be shareable artifacts, but they're structurally distinct.

Failure modes (4)

  1. A bundle works only on the operator's machine because paths, providers, or credentials are implicit. Bundles must be self-describing for a clean OpenRig environment.
  2. A bundle includes too much local state and becomes a backup archive instead of a reusable artifact. Bundle is the intended shape, not the current state of one specific install.
  3. A bundle declares topology but omits proof expectations or workflow mode. Topology alone doesn't tell users what "working as advertised" means.
  4. Users cannot inspect what a bundle will create before installing it. rig bundle inspect must show what will be created without side effects.

Proof standard

Proof should:

  1. Install the bundle into a clean OpenRig environment
  2. Instantiate it
  3. Verify the expected seats and workflow mode
  4. Run a small smoke proof that the topology behaves as advertised

Bundle path → product

Bundles are how proven lab patterns become reusable product experiences:

local dogfood pattern
  → bundle (with manifest, parameterization, proof expectations)
  → installed by another user on clean OpenRig
  → opinionated workflow shipped without becoming a daemon feature
  → if dependable, graduate parts into core daemon

This is also how OpenRig can ship opinionated workflows without making every workflow a daemon feature.

See also

  • extension-and-user-workspace skill — sibling primitive for user-owned behavior added to runtime; bundle vs extension boundary
  • specification-system skill — rig specs / agent specs / workflow specs that bundles package
  • agent-starters skill — bundles can include or reference Agent Starters
  • openrig-user skill — rig bundle create / inspect / install CLI surface

Reviews

No reviews yet. Tell others what you thought.

Comments

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.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

agent-browser

FreeSummary

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.

  • Automating form entry and submission
  • Extracting page text and saving screenshots
  • Comparing page appearance before and after changes
mvschwarz/openrig7.9KUpdated Oct 19, 2026

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.

  • Designing an application operated by OpenRig agents
  • Organizing instructions and shared application state
  • Tracing unexpected behavior to its source
mvschwarz/openrig7.9KUpdated Oct 19, 2026

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.

  • Designing procedures for environments with varying conditions
  • Resuming interrupted operations from verified evidence
  • Deciding whether an agent or ordinary code should control a procedure
mvschwarz/openrig7.9KUpdated Oct 19, 2026

agent-starters

FreeSummary

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.

  • Create reusable startup context for an agent role
  • Refresh an agent workspace from an existing starter
  • Check a starter’s source history and freshness
mvschwarz/openrig7.9KUpdated Oct 19, 2026

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.

  • Designing startup files for a new agent
  • Reviewing stale guidance used by running agents
  • Separating role information from reusable procedures
mvschwarz/openrig7.9KUpdated Oct 19, 2026

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.

  • Configuring command permissions before launching an agent team
  • Reducing repeated approvals for selected rig commands
  • Adding permission rules within a chosen project scope
mvschwarz/openrig7.9KUpdated Oct 19, 2026

See all skills by mvschwarz

Report a problem with this skill