Mirrors registry/workshop.yaml from openrig-registry ae235b69 (#38, Workshop pinned to the 0.7.9 skills at world 37592f8b), byte-equal. One file, +6/-6. Read by the desk against the registry file.
Regenerated with tools/generate-pi-skills.py at the v0.7.9 release commit ddb9d25b (openrig-core 0.1.25). One skill changes: seat-continuity-and-handover's guidance now tells a committed binding apart from a missing lineage record, names the receipt's side-effect provenance and the departing process's outcomes, and says not to repeat a handover only to repair missing provenance, in both the Workshop and review-pair copies; the lock files record the new provenance. Generator --check (20 skills, 44 files), the Workshop/review-pair parity check and the CI bundle check pass. One focused read CLEAR at 8ecc7c7a.
Mirrors registry/workshop.yaml from openrig-registry 7aa8cb31 (#37, Workshop pinned to the 0.7.8 skills at world b7a71ddf), byte-equal. One file, +6/-6. Read by the desk against the registry file.
Regenerated with tools/generate-pi-skills.py at the v0.7.8 release commit 12df562c (openrig-core 0.1.24). One skill line changes: seat-continuity-and-handover now names the handover source fork:<seat>, in both the Workshop and review-pair copies; the lock files record the new provenance. Generator --check (20 skills, 44 files), the Workshop/review-pair parity check and the hosted bundle tools check pass. One focused read CLEAR at e86bb0c7.
The world copy of Workshop's registry entry (`registry/workshop.yaml`) now matches openrig-registry main `26408957` byte for byte: it pins `582084a7`, which carries OpenRig 0.7.5's Pi skill snapshots, with the four regenerated package digests.
Workshop and Workshop Review Pair now carry the public OpenRig skill snapshots from v0.7.5 (`b57c4da3`), openrig-core 0.1.22. The queue handoff skill explains how to park external waits with a continuation and a timed wake. Both bundles keep identical skill bytes and updated source locks, and the skill selection is unchanged.
The generator's `--check` verifies 20 catalog skills and 44 source files against the pinned product commit, and the Workshop/Review Pair parity test passes. This verifies generated bytes, not a native Pi session.
The world repo's copy of the Workshop registry entry (registry/workshop.yaml) now matches openrig-registry after its repin to this repo's 06827206, the 0.7.4 Pi skills: the two source pins and the four regenerated package digests. 1 file.
Workshop's Pi seats don't get skills from the openrig-core plugin, so their skill snapshots are regenerated for each OpenRig release. This regenerates them at OpenRig 0.7.4 (6d9e8e27, plugin 0.1.21) with tools/generate-pi-skills.py and copies the same files to the workshop-review-pair rig. The same 20 skills are selected; queue-handoff gains 0.7.4's guidance on writing a message the receiver can act on after one read. 4 files, +16 -8.
The world repo's copy of the Workshop registry entry (registry/workshop.yaml) now matches openrig-registry after its repin to this repo's 44bfc87c, the 0.7.3 Pi skills: the two source pins and the four regenerated package digests. 1 file, +6 -6.
Workshop's Pi seats don't load skills from the openrig-core plugin, so their snapshots are regenerated for 0.7.3: tools/generate-pi-skills.py against v0.7.3 (0ef6f839), plugin 0.1.20. A Workshop user with Pi seats now gets agents that know 0.7.3's people and shared-channel commands (rig gateway participants, the default person, answering in a shared channel's thread) and that a response is not consent.
The lock moves from 8b180689 / 0.1.19 to 0ef6f839 / 0.1.20 with a new manifest hash. Two skills change in each agent folder (messaging-the-human, and one reworded sentence in claude-compaction-restore); the same 20 skills, and the review-pair folder is a byte copy. 6 files, +88 -20.
The compatibility mirror's Workshop entry is updated byte for byte to the canonical openrig-registry entry (#31): it pins this repository's d1d46383, which carries Workshop's Pi skill snapshots regenerated at OpenRig 0.7.2, with its four configurations' package digests regenerated at assembler 0.6.6. 1 file.
Workshop's Pi seats don't load skills from the openrig-core plugin, so their snapshots are regenerated for 0.7.2: tools/generate-pi-skills.py against v0.7.2 (8b180689), plugin 0.1.19. A Workshop user with Pi seats now gets agents that know 0.7.1's and 0.7.2's commands: per-seat accounts and provider moves, rig mcp serve with tokens, rig seat status, a seat's own skill storage, Steering and the Slack subscription.
The lock moves from c99450f3 / 0.1.17 to 8b180689 / 0.1.19 with a new manifest hash. Five skill files change in each agent folder (openrig-user, messaging-the-human, forming-an-openrig-mental-model, delegating-work, and claude-compaction-restore's precompact hook); the same 20 skills, and the review-pair folder is a byte copy. 12 files, +592 -148.
Brings the openrig-world mirror of the Workshop registry entry back in line with the canonical entry (openrig-registry#25): registry/workshop.yaml is byte-equal to it and to the regeneration evidence (e6074e20), pinned to d139a0c8 (#66) instead of 2a5d93c8 (#63), with the 0.6.6 assembler. The review date and note take the canonical entry's existing 2026-10-18 values, which the mirror had drifted from; no status changes.
Workshop's Pi seats don't load skills from the openrig-core plugin, so their snapshots are regenerated for 0.7.0: tools/generate-pi-skills.py at c99450f3 (tag v0.7.0), lock moved from df1c1517 (0.6.14) to c99450f3 with plugin 0.1.17. Six skills change (claude-compaction-restore, forming-an-openrig-mental-model, messaging-the-human, openrig-skills, openrig-user, queue-handoff), copied byte for byte into the review pair. A native Pi session wasn't run.
Workshop's Claude Code and Codex seats used to load OpenRig's own skills from copies vendored into this repository, which never changed when OpenRig's shipped skills did. They now select the openrig-core plugin from the installed OpenRig (openrig-home:plugins/openrig-core), as the other agents here do, so each seat gets the skills of the OpenRig it runs on. Workshop's own skills are unchanged.
Pi seats keep generated snapshots, regenerated from OpenRig v0.6.14 with tools/generate-pi-skills.py; PI-SKILLS.md says to regenerate them each OpenRig release. Both Workshop rigs and the review-pair variant change the same way.
A project that ran Workshop before keeps its earlier copies until they're moved aside, because OpenRig only replaces skill folders it recorded as its own; the README says which folders to move and when.
Workshop's lead guidance and culture now say that a person's explicit request to push or open a PR stays their authorization when their own installing agent and the operator carry that request into the team's task; the person doesn't have to repeat it in another terminal or name every intermediary. Limits in the task still hold: a setup-only or implementation-only request doesn't imply publishing, a PR request doesn't imply a merge, release or unrelated posts, and a new, conflicting or out-of-scope action still needs the person's decision. The same text is in rigs/workshop and rigs/workshop-review-pair.
openrig-world's 0.6.6 compatibility copy of the Workshop listing now pins rigs/workshop at 2a5d93c8, matching the canonical openrig-registry entry byte for byte. From the old pin only the QA guidance's sandbox paragraph and the startup context's AGENTS.md clause change. The native macOS results stay dated 2026-10-06 and labelled historical.
Workshop's guidance/qa.md now says Codex's workspace-write sandbox applies only when the rig runs in OpenRig's default posture; this rig launches Codex seats with full access, so a QA seat can run rig, install dependencies and start local servers, and the README's 'Codex seats and the sandbox' section covers the default and the opt-in network profile. startup/context.md tells a Codex or Pi seat to read the repository's own AGENTS.md content, not OpenRig's managed block there. The same edits apply to workshop-review-pair. Text only.
A five-seat variant of Workshop in its own folder, rigs/workshop-review-pair: the same team with two independent code reviewers, one Claude Code and one Codex, instead of one. The four-seat Workshop stays the recommended team and is unchanged. The variant's agent folder is an exact copy of Workshop's, and a tools test keeps the two identical.
* Keep the legacy workshop entry in step at 52ca6128
OpenRig 0.6.6 still reads registry/workshop.yaml from this repository.
Update it, byte for byte, to openrig-registry's new workshop entry: the
pin moves to 52ca6128 (#57) with the four new package digests.
* Date the workshop review 2026-10-07
The pinned commit 52ca6128 was made on 2026-10-07, so the listing page
should read "Reviewed for listing on 2026-10-07", not the previous
pin's date.
---------
Co-authored-by: OpenRig contributors <[email protected]>
* docs(workshop): open the seats' terminals where the person can see them
Asked to show the person the team's terminals, an agent ran
`rig terminal open <rig>` from its own shell. The tiles opened where
nobody could see them, and nothing appeared until the person said so.
The using-the-tui-together skill now starts from what the person can
see: only what is open in a terminal they can see. On a desktop,
`rig terminal open <rig> --window` opens the tiles in a new window or
tab in front of them. Headless, such as over SSH, the agent tells them
plainly to open a terminal and gives them the attach command for each
seat. The lead's guidance and the README give the person the same two
routes. Versions before 0.6.7 have no `--window`, so each place names
the attach commands as the way in there.
* docs(workshop): say what --window does from 0.6.7, not why it's needed
From 0.6.7, `rig terminal open` without `--provider` already opens a
window, so "without --window the tiles can open where nobody sees them"
no longer holds. The skill now says `--window` makes the request
explicit, that leaving out `--provider` also opens a window from 0.6.7,
and that `--provider herdr` or `--provider cmux` without `--window`
uses an existing workspace. The intro says that opening a workspace
from your shell doesn't by itself show it to the person.
---------
Co-authored-by: OpenRig contributors <[email protected]>
Refresh the workshop registry pin and all four generated behavior views to openrig-world `8b22d918340504ec2e01889a00b07c71195c459f`, which adds the lead lifecycle notice from #54.
The regenerated archives include the exact lead guidance. Configuration choices, permission and non-interruptive declarations, behavior sections and native-status labels are preserved; package digests and source provenance identify the updated content.
Validation: create and inspect all four preset archives, independently compare member hashes and package digests, then run registry and status checks. No native execution is claimed.
The workshop lead's first-move guidance (`rigs/workshop/startup/lead-first-move.md`, delivered at startup per `rig.yaml`) gains two lines. They're worded the same as the lines given to OpenRig's built-in starter and factory leads in mvschwarz/openrig#895:
> `rig down` and `rig seat stop` end agents' sessions and any work in progress, and `rig up <spec>` on a stopped team's name replaces it with a new team. Don't run them unless the person asked; check `rig ps --nodes` first.
A lead now meets this before it stops or restarts its own team. Text only. Nothing else in the workshop changes, and the registry views are regenerated separately from the merged commit.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai -->
## Summary by CodeRabbit
* **Documentation**
* Updated setup guidance to clarify that `rig down` and `rig seat stop` end agent sessions and any work in progress, while starting a rig with an existing team name replaces that team.
* The guidance now says to run these commands only when requested and to check `rig ps --nodes` first.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Pins the workshop to `40453963fdb092e87946483481d642ff24e2142d`, the merged source from #52, and regenerates all four package digests and behaviour views from actual archives built with OpenRig 0.6.6 candidate `bd094ce2` (mvschwarz/openrig#892).
The views now declare broad access and non-interruptive defaults for Claude Code and Codex seats, retain the explicit opt-out and sign-in limits, and omit the superseded Claude first-warning prerequisite. Pi retains full resource trust without non-interruptive flags. Configuration identities and runtime presets are unchanged. The source declares minimum CLI and daemon versions of 0.6.6; effective native state remains unknown.
Validation: stock build, four create/inspect archive generations, independent member hashes and package digests, source/configuration/view identity checks, registry check and status generation/check all passed. Existing status bytes are unchanged. No native launch or runtime test claim is added.
Workshop now declares `non_interruptive: true` alongside its existing `builtin:yolo` policy, so supported Claude/Codex warning screens can be accepted with per-launch flags without an extra install option. Its README and before-install precondition explain broad access, explicit opt-out, and the remaining sign-in and unsupported-notice limits. Runtime presets remain unchanged data and inherit the rig declaration.
Both minimum CLI and daemon versions are 0.6.6. Link import reads those declarations; a local-folder bundle build must supply both minimum-version flags to preserve them in its archive.
Validation: YAML and configuration preservation checks passed, and all four presets produced the intended declaration and before-install view using product companion mvschwarz/openrig#892 at `33ad6333`. The world registry CI check passed at `99edce3f`. This source must merge before a separate registry commit pins its actual squash SHA and regenerates all four behaviour views from real archives. This PR does not claim native execution.
Both registry entries and their views pin f1d1d8fa on main, which carries factory-rsi's configurations.yaml, so registry consumers read rig.yaml and configurations.yaml from a commit on main. Package digests are unchanged.
factory-rsi declares its existing seven-seat configuration in configurations.yaml, with the canonical ID its registry entry expects, so registry consumers can import it. No seat or runtime changes; package digests are unchanged.
The workshop starts from the person's goal with a Codex lead and reviewer and a Claude Code builder and QA seat, installed once as workshop in ~/rigs/workshop for every runtime configuration. Adds the factory-rsi reference bundle with its registry entry. Registry views, roster and the /rigs listing are regenerated with reproducible package digests.
Repins the workshop listing to openrig-world 888ec465, which carries the README, lead guidance, exclude-line and Claude Code auto-mode corrections, with the four package digests built by the 0.6.6 assembler (recommended 2c332fd1, all-claude ecb465ac, all-codex 3f9459a8, all-pi a3ef4435) and regenerated views. The digests were reproduced independently. Status is unchanged.
The workshop README and the lead's guidance now say how to reach the newly installed team: rig capture and rig send from any shell, tmux attach (or switch-client inside tmux) using the attach command OpenRig prints per seat, bare rig for the TUI, and rig terminal open <rig> when herdr or cmux is available. The lead uses its own rig and session names rather than assuming "workshop". The exclude lines add gate-lane-verdict.json, which the QA seat's npm run gate writes at the worktree root. The note for people who ask Claude Code to do the setup now records that its default auto mode declined the rig up line on macOS with 2.1.289 and 2.1.290 (and, in an earlier 2.1.289 run, a permission rule for itself and rig context add --git), so run those two commands yourself. The vendored developing-openrig and openrig-skills copies are synced to openrig fcef78ab.
Lists the `workshop` reference rig in the registry in place of `openrig-dev`: `registry/workshop.yaml` and its four
behaviour views, pinned at `cb53040c` (the roster fix), assembled with OpenRig 0.6.6. `status/status.json` is
regenerated, and the four configurations read as not yet tested by OpenRig until journey records arrive.
Package digests (independently reproduced from source):
- recommended `67e10fd479d4317568579a444df6969f4b11626ab4a12e0f95ec25e04cdbf375`
- all-claude `fca9ba637a4353bd7f716529ce5f1ecef6d34e0a0c9dbce6c1974c453ea05b4e`
- all-codex `41659ce2723d4f85372c94fbad474ac02e69314bd3703f2de63ffad679bed677`
- all-pi `9bd7fe3a8978a07f3dfe41d4bb15a66a540d1ee6fa4b9250a387fa2d8c352f88`
The workshop lead names the team roster after the rig it actually runs in, taken from `rig whoami --json`
(`identity.rigName`), so a copy launched under another name gets its own roster instead of stopping at an existing
`workshop` one. If the daemon is unreachable and the name is null, the lead skips the roster and tries again at its
next start.
The roster is also kept current: when a seat picks up a capability or specialization worth asking it about, the lead,
as curator, adds it to that member's `capabilities`, adjusts `use_when` or `why` if needed, sets `updated_at`, and runs
`rig roster list` to check it still lists. The builder, code reviewer and QA seats tell the lead when they pick one up.
Starting again never replaces the file.
Text only: role guidance and the README.
Adds rigs/workshop, which replaces rigs/openrig-dev: OpenRig's own rig for building in any repository. A lead proposes one piece of work and asks before starting, a builder makes the change, and a code reviewer and a QA seat check it. Seats are orch-lead, dev-build, review-code and review-qa.
- Culture: a values-only CULTURE.md for any repository.
- Startup and roles: work outside an OpenRig clone (OpenRig-specific steps apply only in one); the lead reads ROADMAP.md and the repository's candidate work, proposes one item and asks first.
- Skills: declared per profile, so they're projected where Claude Code and Codex read them (no plugin entry), plus ponytail (MIT, upstream DietrichGebert/ponytail at 0e3fd0cf, licence included), using-the-tui-together and claude-compaction-restore. The Pi generator appends the bundle's own skills.
- Roster: the lead writes the team's roster at first start if none exists, and the startup text points to rig roster find.
- Exclude list: OpenRig's files (CLAUDE.local.md, AGENTS.md, .claude/settings.local.json, /.openrig/, projected skill folders) stay out of the person's commits.
- Requires OpenRig 0.6.6.
Reviewed independently (CHANGES-NEEDED once, then MERGE-READY at 1769ad1b) and approved on content; spec validation and the Pi generator check pass, CI green. A real launch is checked in the journey round before /rigs links to it.
tools/install-verify.mjs reports, for each seat of an installed rig, whether everything the bundle declares is where that seat's runtime reads it: startup files, OpenRig's default culture and the rig's culture, skills (including each skill of a selected plugin), plugins, MCP servers, runtime resources and the managed block target. Each item is present, missing or unknown, with the reason. It's a report, not a gate: it always exits 0. --json gives the same data, and --declared prints what a seat should have, for comparing with the seat's own listing. Without --home, a skill that isn't in the project's folder reads unknown, because the runtime also reads the user's folder.
When a submission in registry/submissions/ uses a name that's already listed in registry/, the "Submission received" notice now adds: "That name is taken. Choose a distinct one, for example <name>-<your-name>." The match is case-insensitive and covers .yml too. The check still passes and its findings are unchanged; a maintainer helps if needed. registry/submissions/README.md says the same in one line.
* registry: openrig-dev at 0aacdc8e, with the README's setup notes
Pins the openrig-dev entry to 0aacdc8e, which carries the README's new setup
notes, and regenerates its four behaviour views and status/status.json.
README.md is packaged, so every configuration gets a new package digest. Among
packaged files, each new package differs from the tested ones only in README.md:
recommended from c8841e17 (macOS run) and eaf7c450 (Linux run), and all-claude
from b12ea96d. The entry declares evidenceReuse for those three. Every status
label, date, assistance count and record stays as it was. The new digests are
added beside the tested ones.
* registry: pin openrig-dev to 94af8cac, with the setup notes as preconditions
Rebuilds the entry, its four behaviour views and status/status.json at
94af8cac, which adds the README's two setup notes to bundle.yaml as
preconditions. Each view now lists five preconditions.
bundle.yaml is outside the package digest, so every package digest is the
same as at 0aacdc8e, and status/status.json is byte-identical. Among packaged
files, each package still differs from the tested ones (c8841e17, eaf7c450,
b12ea96d) only in README.md. The reuse reasons now also mention the
display-only preconditions.
---------
Co-authored-by: OpenRig contributors <[email protected]>
The listing shows a bundle's preconditions before install, and rig up prints
them too, but the two setup notes added to the README weren't among them. Add
them as preconditions in the README's wording, after the clone and
context-pack step they apply to:
- rig context add needs a running daemon; if it stops with "Daemon not
running.", run rig daemon start and add the pack again.
- If Claude Code does the setup, its default auto mode (2.1.289, tested on
macOS) declined three steps; each one is named, with its label and what the
person does instead.
rig daemon start stays in the text, not in the commands list: the commands run
in order, and it fails when a daemon is already running.
Co-authored-by: OpenRig contributors <[email protected]>
The optional rig context add step comes before rig up, and without a running
daemon it stops with "Daemon not running." Say so, and say to run rig daemon
start first.
Add a short note for people who ask Claude Code to do the setup. In a test on
macOS with Claude Code 2.1.289, its default auto mode declined three steps:
cloning and building the openrig repository, adding a permission rule for
itself, and rig context add --git. The note names each one, with the label
Claude Code shows, and says what the person does instead.
Co-authored-by: OpenRig contributors <[email protected]>
Regenerates status/status.json with tools/status.mjs from the run records for
openrig-dev. A new run of the recommended configuration on darwin-arm64
(OpenRig 0.6.6, the listed package c8841e17) passed every step of the
contributor-team journey through ready-to-submit, with 12 assisted inputs. The
configuration gains a darwin-arm64 entry labelled tested_with_help. The
linux-x64 entries are unchanged.
Co-authored-by: OpenRig contributors <[email protected]>
A stranger submitting a rig had no way to pass the registry check: anything in
registry/ that wasn't a full registry-entry.v1 (pinned commit, digests, views)
failed. Submissions now go in registry/submissions/<name>.yaml with three
fields, repository, folder and ref, checked against a small schema that reuses
the entry format's own repository and folder rules. A well-formed submission
passes with "Submission received", shown as a notice on the pull request. A
malformed one fails and says what a submission needs. A file beside the entries
that has no configurations is pointed to submissions/.
Submissions are never listings: the status generator and the site read only
registry/*.yaml, so a merged submission changes nothing they produce. File names
in submissions/ are limited to plain characters, because they are echoed into CI
output.
Co-authored-by: OpenRig contributors <[email protected]>
Regenerates status/status.json with tools/status.mjs from the openrig-dev run
records. The all-claude run's record was re-issued with a clearer public note,
superseding the earlier copy: install, launch and orientation passed with no
input, and getting a change ready to submit was not tested. The label stays
partly_tested; the entry now cites the re-issued record. Nothing else changes.
Co-authored-by: OpenRig contributors <[email protected]>
The status rule carried a record's publicNote only on a Known problem label, so
a Partly tested label could not say what the run left out. Partly tested now
carries the deciding record's publicNote as note too, when it has one. The
schema already allows note on any label. Tested and Tested with help are
unchanged. The README states the rule, and a test covers a partly tested record
with and without a note; with the old rule that test fails.
status/status.json regenerates with the all-claude entry's note; nothing else
changes.
Co-authored-by: OpenRig contributors <[email protected]>
Regenerates status/status.json with tools/status.mjs from the run records for
openrig-dev. A new all-claude run on linux-x64 (OpenRig 0.6.6, the listed
package b12ea96d) passed install, launch and orientation with no assistance, and
its record resolves the earlier run's launch failure. The configuration now reads
partly_tested: ready-to-submit was not run. The recommended configuration stays
tested_with_help; all-codex and all-pi stay "Not tested by OpenRig".
Co-authored-by: OpenRig contributors <[email protected]>
Moves the listing to 64c7efdd (README: continuing a stalled seat with rig seat
continue) and rebuilds the four configurations with OpenRig 0.6.6 at 106dbf86.
The package digests change because rigs/openrig-dev/README.md changed; the
behaviour views are otherwise unchanged.
Of the 50 packaged files, only README.md differs from each tested package, so
recommended keeps evidenceReuse for eaf7c450 and all-claude gains evidenceReuse
for 2c3bbb40. status/status.json regenerates from the same two run records:
recommended still reads tested_with_help and all-claude known_problem, each now
citing the new listed digest beside the package that ran.
Co-authored-by: OpenRig contributors <[email protected]>
A Claude seat that stopped at Claude Code's bypass warning now shows as
needing attention and keeps its startup text (OpenRig 0.6.6). The README's
recovery is: accept the warning in that seat, then rig seat continue <seat>
(or c in the TUI), and the start steps arrive in the same conversation. The
rig down and --existing --fresh route stays only as the 0.6.5 fallback.
Co-authored-by: dev50-planner <[email protected]>
Regenerates status/status.json with tools/status.mjs from the run records for
openrig-dev. The all-claude configuration on linux-x64 now reads known_problem
(OpenRig 0.6.6, package 2c3bbb40): two of four Claude seats did not answer their
startup check. The record's public note explains why. The recommended
configuration stays tested_with_help; all-codex and all-pi stay "Not tested by
OpenRig".
Co-authored-by: OpenRig contributors <[email protected]>
The behaviour schema gained two optional posture properties
(mvschwarz/openrig#738): nonInterruptive, which must be "available", and
firstRunWarnings.claudeBypass, which must be "harness_asks_once". The other four
schemas are unchanged. source.json now pins 6f783f67 with the new behaviour
schema's SHA-256, and a test shows the registry check rejects any other value;
with the old pin that test fails.
Co-authored-by: OpenRig contributors <[email protected]>
Mike Schwarz