0 Fork 0

mirror of https://github.com/mvschwarz/openrig.git synced 2026-11-07 05:56:21 -10:00

Files

T

Mike Schwarz b9dd23db87 docs(bundles): say at submission that an exported team needs a declared README (#2176 )

Someone submitting a team to openrig.dev/rigs now learns before they submit that the registry's check runs rig bundle check on their folder at the submitted ref with the latest published OpenRig, and that any finding fails it. An exported team has no README of its own, so the publishing guide's submit section and the rig-bundles-and-shareable-artifacts skill now say to add one, declare it in rig.yaml docs, and run rig bundle check at the commit being submitted. The skill gains a short section from an exported team to a submission; its mirror and edge digests are regenerated.

4 files, +29 -2 (docs and skill text only). No behaviour, flag or check changes.

2026-10-27 03:59:27 -07:00

_canonical

docs(bundles): say at submission that an exported team needs a declared README (#2176 )

2026-10-27 03:59:27 -07:00

rigs

docs(herdr): reopening adds a workspace unless you use --window; Herdr's status is its own (#2032 )

2026-10-25 09:05:34 -07:00

CHANGELOG.md

curate bundled starter skills

2026-05-10 03:19:51 -07:00

LICENSE

skills: in-repo mirror of canonical bundled skills at skills/_canonical/

2026-05-08 20:51:37 -07:00

README.md

build: read leak-guard rules from an optional local file (#2137 )

2026-10-26 18:46:46 -07:00

README.md

OpenRig Skills

This folder is the publicly-visible mirror of the canonical skills that ship with OpenRig — the set of progressive-disclosure context manifests that OpenRig agents load on demand to do their work well.

The skills are mirrored from the daemon's bundled-skills folder at packages/daemon/specs/agents/shared/skills/ into _canonical/ here, so that anyone reading the openrig repo can find the skills at the repo root without spelunking through packages/daemon/specs/.

What you'll find

Path	Contents
`_canonical/`	The mirrored skills, organized by category (`core/`, `pm/`, `pods/`, `process/`) plus a few uncategorized at the root. Do not edit files here directly — see "Authoring" below.
`rigs/`	The `rigs` skill: a route into OpenRig for an ordinary Claude Code or Codex session. It isn't mirrored; see "Using these skills".
`CHANGELOG.md`	Append-only log of skill changes per curation cycle close. Hand-authored.
`LICENSE`	OpenRig's Apache-2.0 license. Vendored skill folders include their upstream `LICENSE.txt` files.

What a skill is

A skill in OpenRig is a primitive for progressive-disclosure context injection, not a unit of capability in the dictionary sense. Frontmatter sits in the agent's hot tier (cheap pattern-matching against the trigger description); body loads on activation; references in the folder load on demand. Read a few _canonical/*/SKILL.md files to see the shape — the frontmatter description is the trigger, and the body is what the agent loads when the trigger matches.

OpenRig agents discover skills automatically; you generally don't invoke a skill explicitly. Authoring a skill is about naming a recurring need with a precise enough trigger that the agent reaches for it at the right moment.

Using these skills

If you're running OpenRig (npm install -g @openrig/cli or via tarball), these skills ship in the package, and each seat gets the ones its profile selects. You don't have to do anything.

The rigs skill is the exception: it's for a Claude Code or Codex session that isn't part of a team yet, so no seat's profile selects it. Add it with npx skills add mvschwarz/openrig --skill rigs. Once OpenRig is installed, its daemon also installs rigs into ~/.claude/skills and ~/.agents/skills, and refreshes it on each upgrade. A copy you added with skills.sh stays as it is. The package carries rigs at packages/daemon/assets/skills/rigs, kept identical to skills/rigs by a test; edit skills/rigs and copy it there.

If you're reading this folder for reference (without OpenRig installed), the SKILL.md files are pure markdown with YAML frontmatter; they're human-readable and self-describing. Each description field in the frontmatter says when to reach for the skill.

Authoring

Each shipped skill has one editable home in this repository:

packages/daemon/specs/agents/shared/skills/<category>/<skill>/ for a skill that daemon seats load from specs;
packages/daemon/assets/plugins/openrig-core/skills/<skill>/ for a skill that ships only in the openrig-core plugin.

scripts/skill-edge-layout.generated.json says which copies each skill has. npm run mirror-skills regenerates every other copy from the home: this folder's _canonical/, and the plugin copy of a spec skill that the plugin also carries. It reads nothing outside the repository. Never edit a generated copy; edit the home and re-run the script before commit.

A home must already be publishable: the script refuses to regenerate when a home holds text or files that the public copies would drop, such as an internal fence, a frontmatter key the publishing rules drop (scripts/leak-guard-rules.mjs), a feedback.md, or an evals/ folder. A skill change from anywhere else comes in as a normal pull request that edits its home.

Drift detection

npm run test:repo runs mirror-skills --check. It fails when a generated copy differs from its home, when a home isn't publishable, when a file doesn't match scripts/skill-edge-digests.generated.json, or when a SKILL.md isn't in the layout. Fix the home, then run npm run mirror-skills and commit the result.

Future-state

This folder is structured as if it were already its own repo so that a future git subtree split --prefix=skills HEAD is mechanical when growth warrants. Until then, the in-repo mirror is the right scope: skill changes ship atomically with the daemon binary that loads them; no version-skew risk; one PR for both halves.