mirror of
https://github.com/mvschwarz/openrig-world.git
synced 2026-11-07 05:56:22 -10:00
workshop: Pi skill snapshots regenerated at OpenRig 0.7.0 (#66)
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.
This commit is contained in:
Mike Schwarz authored and GitHub committed
1 parent
47388efc95
commit
d139a0c838
14 files changed
+170
-74
No files matched your search
@@ -1,9 +1,9 @@
|
||||
{
|
||||
"productRepository": "https://github.com/mvschwarz/openrig",
|
||||
"productCommit": "df1c1517f03a403fb468523be1c563d489209a1d",
|
||||
"productCommit": "c99450f322646acd6bcd93e11a3bd1474f1d7751",
|
||||
"pluginPath": "packages/daemon/assets/plugins/openrig-core",
|
||||
"pluginVersion": "0.1.15",
|
||||
"pluginManifestSha256": "f630b87ff9197e621f56c5f68ff2482d35fa2ef395bc92cfe60e4a78e4e489d1",
|
||||
"pluginVersion": "0.1.17",
|
||||
"pluginManifestSha256": "724c5061998abdd7ca42575628ccb526fafdeab7b27992084fffe0d1b2ecffde",
|
||||
"piUnselectedSkills": [
|
||||
"claude-compaction-restore"
|
||||
],
|
||||
@@ -58,7 +58,7 @@
|
||||
"path": "skills/claude-compaction-restore/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/claude-compaction-restore/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "a9d309e42c9579dfcc0d719e42950db2ed45cd7e4e68ab00727630a090751394"
|
||||
"sha256": "623b00143111a1ad695c72c86bcf0792bbccd1b4a6d250a1cde27145513960ae"
|
||||
},
|
||||
{
|
||||
"path": "skills/claude-compaction-restore/reference/SKILL-v1.md",
|
||||
@@ -106,7 +106,7 @@
|
||||
"path": "skills/forming-an-openrig-mental-model/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/forming-an-openrig-mental-model/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "a1c14e7e61bbb2b56739ff56ff8d6dd8e9e9d37969db9f1e7b278cf0f650b43f"
|
||||
"sha256": "68307c60a5d8d5d93cbd86e28399b73f336a7f13ebe6e30e9a7b22e818dc7022"
|
||||
},
|
||||
{
|
||||
"path": "skills/loading-addressable-markdown/SKILL.md",
|
||||
@@ -124,7 +124,7 @@
|
||||
"path": "skills/messaging-the-human/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/messaging-the-human/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "4804d32fe66db050722caf2b43f8b868ca65b3dfcf2f2830f8f4859726f6f1b0"
|
||||
"sha256": "d504477d1e7df04259d750187071ed96e0419f0e5df3358767d53c2ba409e84d"
|
||||
},
|
||||
{
|
||||
"path": "skills/mission-slice-sop/SKILL.md",
|
||||
@@ -202,13 +202,13 @@
|
||||
"path": "skills/openrig-skills/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/openrig-skills/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "c30ca27054b4253db09dc45b7d3e029d8d81f9019f2a1b487d6ca0ca2b99bbf5"
|
||||
"sha256": "bdd6594ae1108455103239d39694c865cc40d3f7d9f24cd3566a18397df270da"
|
||||
},
|
||||
{
|
||||
"path": "skills/openrig-user/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/openrig-user/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "8091a8ddda9c53a49bf7ebe0b7d78dda797efc43aa3cf4bfad09b58e92e27d7d"
|
||||
"sha256": "cf2fd3f2cf4d7c5182b63ae42e0c2eaf23fb6ddbbc61cef0b26d0d9536ca2476"
|
||||
},
|
||||
{
|
||||
"path": "skills/orienting-to-an-inherited-seat/CHANGELOG.md",
|
||||
@@ -226,7 +226,7 @@
|
||||
"path": "skills/queue-handoff/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/queue-handoff/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "5ff22b30a632b9832dcefa6a107866ef06fc3991f8d7d9f367394eb88261be1c"
|
||||
"sha256": "fcfa420a49a09be4fd51ccc6ca89c00847a59484a7bcab205c8eec83837cdc0d"
|
||||
},
|
||||
{
|
||||
"path": "skills/refocusing/SKILL.md",
|
||||
|
||||
@@ -221,12 +221,19 @@ The audit message asks for a read-depth table and tells you not to conserve toke
|
||||
|
||||
The next restore map links this note, which keeps the chain unbroken.
|
||||
|
||||
## Then resume
|
||||
|
||||
Resume the outcome selected by the user's current instructions, standing duties and assigned work. Use existing
|
||||
task records, decisions and your recap to recover the next useful action, remaining constraints and evidence
|
||||
already earned. Check uncertain effects before replaying work. Available skills and historical suggestions do not
|
||||
by themselves widen scope or create required stages. Use authorized skills, subagents, peer help and useful tests
|
||||
within your remit without another permission request. Route a missing decision to its existing owner and continue
|
||||
unaffected work.
|
||||
|
||||
## Guardrails
|
||||
|
||||
- Compaction is survival, not housekeeping. Compact only when a seat is genuinely near its limit, never to
|
||||
"lean" a seat or prepare a starter image; a compacted seat can sound confident while missing the context it needs.
|
||||
- Continue from the map and the files, not from the summary's "next step" alone: a hold placed after the
|
||||
summary was written still binds.
|
||||
- Do not launch a fresh session in place of restoring.
|
||||
- An honest `PARTIAL` with its reason is a correct outcome. Claiming coverage you did not reach is the
|
||||
failure.
|
||||
|
||||
+3
-2
@@ -242,8 +242,9 @@ If you're booting into a new seat in an OpenRig rig:
|
||||
4. **Check what skills you have** — list `.claude/skills/` or
|
||||
`.agents/skills/` in your cwd. Each skill has a frontmatter description
|
||||
that tells you when to reach for it.
|
||||
5. **Check your peers** — `rig capture <peer-session>` to see what they're
|
||||
doing.
|
||||
5. **Check your peers** — `rig ps --nodes` and the queue first (who is up,
|
||||
who holds what). Capture a peer (`rig capture <peer-session>`) only when
|
||||
you actually need to see its screen.
|
||||
6. **Check the transcripts** if you're returning to an in-flight workstream
|
||||
— `rig transcript <session> --tail 100` for recent context.
|
||||
7. **Ask `rig ask <rig> "<question>"`** if you need cross-cutting evidence
|
||||
|
||||
@@ -5,6 +5,8 @@ metadata:
|
||||
cli_surfaces_referenced:
|
||||
- gateway human list
|
||||
- gateway human show
|
||||
- gateway human mode room
|
||||
- gateway human mode decide
|
||||
- queue create
|
||||
- queue transitions
|
||||
- queue block
|
||||
@@ -69,6 +71,28 @@ rig queue create --destination <entityId>@external \
|
||||
--evidence-ref <durable-evidence> --verify --json
|
||||
```
|
||||
|
||||
Before asking a **decision**, check whether the person has a mode on with a
|
||||
decision room: what they said the team may decide for them meanwhile.
|
||||
|
||||
```bash
|
||||
rig gateway human mode room <entityId>
|
||||
```
|
||||
|
||||
If it names a room and your decision is plainly inside their words (and none of
|
||||
their exclusions), decide instead of waiting. Create the ask as above, then
|
||||
record your choice on it straight away:
|
||||
|
||||
```bash
|
||||
rig gateway human mode decide <qitem-id> --application <applicationId> \
|
||||
--choose <question>=<option> --reason "<why>" --reversible # or --irreversible
|
||||
```
|
||||
|
||||
It's recorded as decided on their behalf, never as their answer, the ask
|
||||
closes, and it's in their account when they're back. Say honestly whether it
|
||||
can be undone. A permission prompt or an approval is never decided this way.
|
||||
With no room, a room that doesn't plainly cover it, or any doubt, ask and wait;
|
||||
a recommended option is not a decision.
|
||||
|
||||
An optional `--human-detail-file <path>` supplies one coherent supplemental
|
||||
reply in the same thread. Announce its purpose in the brief; the product also
|
||||
marks that a detail reply follows. The primary must already contain the complete
|
||||
|
||||
@@ -91,7 +91,7 @@ These ship in the OpenRig repo and reach a seat when its profile selects them. T
|
||||
Pod handbooks (load when you're in that pod):
|
||||
- **orchestration-team** — you're orchestrating a rig: dispatching, monitoring, keeping the loop moving.
|
||||
- **development-team** — you're on the dev pod: building and shipping product changes.
|
||||
- **review-team** — you're reviewing: fresh scrutiny, anti-slop, empirical verification.
|
||||
- **review-team** — you're reviewing: fresh scrutiny, anti-slop, grounded findings.
|
||||
- **oversight-team** — you're in an oversight pod: monitor boundaries and route findings without taking over the work.
|
||||
|
||||
Product-management craft (load when shaping/reviewing work):
|
||||
@@ -106,7 +106,7 @@ Product-management craft (load when shaping/reviewing work):
|
||||
### Vendored craft — load when you're coding (ships with upstream provenance)
|
||||
General engineering skills OpenRig ships as vendored copies. Open when the task matches; they carry "modified by OpenRig" provenance.
|
||||
|
||||
- **verification-before-completion** — about to claim done / passing / fixed: run the check and read the output first.
|
||||
- **verification-before-completion** — about to claim done / passing / fixed: have evidence that applies to the candidate you name first.
|
||||
- **systematic-debugging** — debugging: find the root cause before the fix.
|
||||
- **agent-browser** — driving a browser (screenshot / screencast) from an agent.
|
||||
- **frontend-design** — designing frontend / UI.
|
||||
|
||||
@@ -90,6 +90,23 @@ rig queue handoff <qitem-id> \
|
||||
--body-file /tmp/import-report-handoff.md
|
||||
```
|
||||
|
||||
### After a queue write — use the response; read back only when it doesn't show what you need
|
||||
|
||||
A queue write (`create`, `claim`, `update`, `handoff`, `handoff-and-complete`) answers with the row it wrote; a
|
||||
handoff answers with the closed row and its successor. When that answer shows what you need to establish, use it.
|
||||
Read back (`rig queue show <id> --full --json`, or `rig queue transitions <id>`) when it doesn't, for example:
|
||||
|
||||
- the outcome was INDETERMINATE (a transport failure, or a 502 `remote_queue_write_failed`), or the write warned
|
||||
`qitem_body_not_saved` (an existing row came back). Reconcile by the original ID before any retry;
|
||||
- the output was compact or truncated and the field you need isn't in it (the compact receipt shows `bodyBytes`, not
|
||||
the body, and its footer names what it left out);
|
||||
- you need a transition note, a closure or blocker detail, or a successor that the output you saw omits;
|
||||
- you need evidence from downstream of the write: the recipient's wake (`create --verify` waits for it), or its
|
||||
pickup or claim (a later read);
|
||||
- your team's custody rule asks for a separate read-back.
|
||||
|
||||
Don't read back only to see again a field the response already showed you.
|
||||
|
||||
### §1b doctrine — turn ends by passing the ball
|
||||
|
||||
**A turn ends by passing the ball, never by going idle holding the slice waiting
|
||||
@@ -956,12 +973,7 @@ rig auth seats … --runtime codex # seat -> profile registry (metadata
|
||||
|
||||
### Manage subscriptions across a fleet (when the person asks you to)
|
||||
|
||||
**This applies only when both hold:**
|
||||
- the daemon's `provider.subscription_moves` setting is on. It's off by default; the person turns it on with
|
||||
`rig config set provider.subscription_moves true`;
|
||||
- the person has asked you to manage their subscriptions.
|
||||
|
||||
Otherwise, don't take this job on. Installing or upgrading OpenRig appoints no agent, launches no bundle and starts no
|
||||
**This applies only when the person has asked you to manage their subscriptions.** Otherwise, don't take this job on. Installing or upgrading OpenRig appoints no agent, launches no bundle and starts no
|
||||
rotation.
|
||||
|
||||
When a person runs several Claude and Codex subscriptions across machines, the fleet studio bundle's one agent is meant
|
||||
@@ -969,19 +981,19 @@ to keep work running, through the Fleet app. Until that bundle is available, the
|
||||
subscriptions can use this section. If that's you, you decide which subscription or home moves, and when. You decide
|
||||
from:
|
||||
- the usage and assignment readings, and their freshness;
|
||||
- the move record;
|
||||
- your earlier move reports;
|
||||
- the person's standing preferences.
|
||||
|
||||
You say why, and you see the outcome through. OpenRig gives you the facts and the tools; it never decides for you,
|
||||
and there's no threshold to obey.
|
||||
|
||||
**Who decides:**
|
||||
- **The person's operator agent** can ask you for a move, or look at the record. It doesn't make competing moves of
|
||||
- **The person's operator agent** can ask you for a move, or ask what you've moved. It doesn't make competing moves of
|
||||
its own.
|
||||
- **One agent manages subscriptions:** the one the person asked, or the fleet studio's agent once that bundle is
|
||||
available. There's no other fleet-manager role and no automatic manager. Use the commands below directly; no extra
|
||||
hand-off is needed.
|
||||
- **The Observatory is optional:** it can show your moves and readings, but you don't need it to rotate.
|
||||
- **The Observatory is optional:** it can show readings, but you don't need it to rotate.
|
||||
|
||||
**The unit is a Codex home, with every seat on it.** Moving some seats on a shared home to a different account, and
|
||||
moving Claude seats, aren't supported moves yet: say so instead of improvising.
|
||||
@@ -1013,8 +1025,7 @@ moving Claude seats, aren't supported moves yet: say so instead of improvising.
|
||||
--expect-account <the target's Account line>`. `--verify` only checks; it never restarts. Only that check
|
||||
reports `moved`, and anything less is unconfirmed.
|
||||
- **A slow reply isn't a failure:** never restart a seat a second time. Follow up at your next look.
|
||||
5. **Record every move, partial or unconfirmed included,** with `rig provider moves record --file <move.json>`
|
||||
(`--help` shows the shape):
|
||||
5. **Report every move, partial or unconfirmed included,** to whoever asked for it (a queue item to their seat):
|
||||
- the home and machine;
|
||||
- from and to, as labels;
|
||||
- your reason;
|
||||
@@ -1022,10 +1033,8 @@ moving Claude seats, aren't supported moves yet: say so instead of improvising.
|
||||
- each seat's result (`moved`, `unconfirmed` or `unknown`) with its evidence or what's missing;
|
||||
- the peers, for example "not restarted; account unverified".
|
||||
|
||||
A seat marked `moved` needs its `evidence`, and an `unconfirmed` or `unknown` one needs what's `missing`. A home
|
||||
switched with every seat left as a peer is still a move to record, with `seats: []`. A follow-up that confirms an
|
||||
earlier unconfirmed seat records a new move with `supersedes`. Asked "why did this
|
||||
seat move?", answer from `rig provider moves --seat <seat>`. Never put credentials in a record.
|
||||
A home switched with every seat left as a peer is still a move to report. A follow-up that confirms an earlier
|
||||
unconfirmed seat says which report it follows. Never put credentials in a report.
|
||||
6. **When a sign-in is needed:**
|
||||
- Ask the person once, durably: a queue item to their seat, naming the machine and the subscription.
|
||||
- Move nothing onto that subscription until it's done.
|
||||
@@ -1393,9 +1402,10 @@ or `rig add` (one member) when a seat needs an explicit model, a permission poli
|
||||
different agent spec or role profile, per-seat runtime or cwd, or startup files.
|
||||
|
||||
Node-granular managed partial restore (v0.3.4+):
|
||||
- `rig launch <rig> <nodeRef>` relaunches a single seat by logical id or node id through orchestration. `<rig>` is the
|
||||
rig's name or ID; a name shared by more than one active rig stops with the candidate IDs.
|
||||
- `rig launch <rig> --seats <a,b,c>` relaunches a comma-separated subset of seats.
|
||||
- `rig launch <rig> <nodeRef>` launches a single seat that isn't running, by logical id or node id, through orchestration.
|
||||
`<rig>` is the rig's name or ID; a name shared by more than one active rig stops with the candidate IDs. A seat that's
|
||||
already running is left as it is; for a fresh occupant there, use `rig seat launch <seat> --fresh --stop --reason <why>`.
|
||||
- `rig launch <rig> --seats <a,b,c>` launches a comma-separated subset of seats.
|
||||
- `--hold-reason <text>` records a reason for holding non-target seats during the partial launch.
|
||||
- This is a SUPPORTED managed path. The prior `pod_aware_launch_unsupported` dead-end is retired; pod-aware narrow launch now goes through this surface rather than ad-hoc rebuilds.
|
||||
|
||||
|
||||
@@ -29,8 +29,9 @@ without an owner.
|
||||
with the rig appearing dormant.
|
||||
- **Finishing a slice that has a clear next step.** Default-nudge:
|
||||
receiver gets a wake-ping plus the durable queue item.
|
||||
- **Blocked on another agent's work.** Park the qitem with
|
||||
`closure_reason: blocked_on` and the blocker qitem id.
|
||||
- **Blocked on another agent's work.** Use `rig queue block <id> --on <child>`
|
||||
(or `rig queue update <id> --state blocked --blocked-on <child>`). The item
|
||||
stays active and returns to pending when its blocker completes.
|
||||
- **Escalating to the human.** Make the escalation a durable attention
|
||||
item, not just a chat message.
|
||||
|
||||
@@ -53,16 +54,20 @@ human. The qitem state machine enforces this:
|
||||
`pending → in-progress → done` requires `closure_reason` from one of:
|
||||
|
||||
- `handed_off_to` — work continues at a different seat (target = new owner)
|
||||
- `blocked_on` — parked pending another qitem (target = blocker qitem id)
|
||||
- `denied` — receiver rejected the work
|
||||
- `canceled` — sender or receiver withdrew
|
||||
- `no-follow-on` — terminal completion, nothing else needed
|
||||
- `escalation` — kicked up to a higher tier (target = escalation target)
|
||||
- `superseded` — replaced by another qitem (target = successor qitem id)
|
||||
|
||||
Three of those (`handed_off_to`, `blocked_on`, `escalation`) additionally
|
||||
Two of those (`handed_off_to`, `escalation`) additionally
|
||||
require `closure_target`. The daemon enforces this at the domain layer;
|
||||
every surface (CLI, MCP, future UI) inherits the same guarantee.
|
||||
|
||||
`done` is terminal. `closure_reason: blocked_on` is valid only on an active
|
||||
`state=blocked` park record, as used by workflow writers; combining it with
|
||||
`state=done` is rejected. Use the block command above to wait on another qitem.
|
||||
|
||||
**The drafted-park failure (draft ≠ throw).** The rule is about the *actual* pass, not the
|
||||
intention to pass. A turn that ends with a self-instruction **typed into your own prompt but left
|
||||
unsent** — a drafted go-ahead, a next-atom note you never sent — has **not** handed off; it has
|
||||
@@ -120,6 +125,7 @@ inverted the default-nudge polarity.
|
||||
- **Scope tags `project:<id>`, `mission:<id>`, `slice:<id>`** on project work, set when you create the row (`--tags`; `create` also takes `--mission` and `--slice`). Tags can't be edited afterwards. A handoff keeps the source row's tags unless you pass `--tags` or `--gate`, either of which replaces them; repeat the scope tags in `--tags` when you use `--gate`.
|
||||
- **Pass work on with `handoff-and-complete`.** It closes your row as done and records the next row as its successor in one step. A `create` followed by `update --state done --closure-reason handed_off_to` records no successor, and the stuck sweep raises a recovery item for it.
|
||||
- **Close what you hold.** A row you claimed ends in a handoff or an `update --state done --closure-reason …`; `rig queue overdue` lists claimed rows past their deadline.
|
||||
- **Use the write's response.** Read the row back only when the response doesn't show what you need (an indeterminate outcome, a field the compact output left out, downstream wake or pickup, a team custody rule): openrig-user, "After a queue write".
|
||||
- **Brief for the model that will read it.** Before handing a peer open-ended work, check which model it runs: `delegating-work`, "Check what kind of agent you're handing it to".
|
||||
|
||||
## Queue-body hygiene (token + parse safety)
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
{
|
||||
"productRepository": "https://github.com/mvschwarz/openrig",
|
||||
"productCommit": "df1c1517f03a403fb468523be1c563d489209a1d",
|
||||
"productCommit": "c99450f322646acd6bcd93e11a3bd1474f1d7751",
|
||||
"pluginPath": "packages/daemon/assets/plugins/openrig-core",
|
||||
"pluginVersion": "0.1.15",
|
||||
"pluginManifestSha256": "f630b87ff9197e621f56c5f68ff2482d35fa2ef395bc92cfe60e4a78e4e489d1",
|
||||
"pluginVersion": "0.1.17",
|
||||
"pluginManifestSha256": "724c5061998abdd7ca42575628ccb526fafdeab7b27992084fffe0d1b2ecffde",
|
||||
"piUnselectedSkills": [
|
||||
"claude-compaction-restore"
|
||||
],
|
||||
@@ -58,7 +58,7 @@
|
||||
"path": "skills/claude-compaction-restore/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/claude-compaction-restore/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "a9d309e42c9579dfcc0d719e42950db2ed45cd7e4e68ab00727630a090751394"
|
||||
"sha256": "623b00143111a1ad695c72c86bcf0792bbccd1b4a6d250a1cde27145513960ae"
|
||||
},
|
||||
{
|
||||
"path": "skills/claude-compaction-restore/reference/SKILL-v1.md",
|
||||
@@ -106,7 +106,7 @@
|
||||
"path": "skills/forming-an-openrig-mental-model/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/forming-an-openrig-mental-model/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "a1c14e7e61bbb2b56739ff56ff8d6dd8e9e9d37969db9f1e7b278cf0f650b43f"
|
||||
"sha256": "68307c60a5d8d5d93cbd86e28399b73f336a7f13ebe6e30e9a7b22e818dc7022"
|
||||
},
|
||||
{
|
||||
"path": "skills/loading-addressable-markdown/SKILL.md",
|
||||
@@ -124,7 +124,7 @@
|
||||
"path": "skills/messaging-the-human/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/messaging-the-human/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "4804d32fe66db050722caf2b43f8b868ca65b3dfcf2f2830f8f4859726f6f1b0"
|
||||
"sha256": "d504477d1e7df04259d750187071ed96e0419f0e5df3358767d53c2ba409e84d"
|
||||
},
|
||||
{
|
||||
"path": "skills/mission-slice-sop/SKILL.md",
|
||||
@@ -202,13 +202,13 @@
|
||||
"path": "skills/openrig-skills/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/openrig-skills/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "c30ca27054b4253db09dc45b7d3e029d8d81f9019f2a1b487d6ca0ca2b99bbf5"
|
||||
"sha256": "bdd6594ae1108455103239d39694c865cc40d3f7d9f24cd3566a18397df270da"
|
||||
},
|
||||
{
|
||||
"path": "skills/openrig-user/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/openrig-user/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "8091a8ddda9c53a49bf7ebe0b7d78dda797efc43aa3cf4bfad09b58e92e27d7d"
|
||||
"sha256": "cf2fd3f2cf4d7c5182b63ae42e0c2eaf23fb6ddbbc61cef0b26d0d9536ca2476"
|
||||
},
|
||||
{
|
||||
"path": "skills/orienting-to-an-inherited-seat/CHANGELOG.md",
|
||||
@@ -226,7 +226,7 @@
|
||||
"path": "skills/queue-handoff/SKILL.md",
|
||||
"source": "packages/daemon/assets/plugins/openrig-core/skills/queue-handoff/SKILL.md",
|
||||
"mode": "100644",
|
||||
"sha256": "5ff22b30a632b9832dcefa6a107866ef06fc3991f8d7d9f367394eb88261be1c"
|
||||
"sha256": "fcfa420a49a09be4fd51ccc6ca89c00847a59484a7bcab205c8eec83837cdc0d"
|
||||
},
|
||||
{
|
||||
"path": "skills/refocusing/SKILL.md",
|
||||
|
||||
@@ -221,12 +221,19 @@ The audit message asks for a read-depth table and tells you not to conserve toke
|
||||
|
||||
The next restore map links this note, which keeps the chain unbroken.
|
||||
|
||||
## Then resume
|
||||
|
||||
Resume the outcome selected by the user's current instructions, standing duties and assigned work. Use existing
|
||||
task records, decisions and your recap to recover the next useful action, remaining constraints and evidence
|
||||
already earned. Check uncertain effects before replaying work. Available skills and historical suggestions do not
|
||||
by themselves widen scope or create required stages. Use authorized skills, subagents, peer help and useful tests
|
||||
within your remit without another permission request. Route a missing decision to its existing owner and continue
|
||||
unaffected work.
|
||||
|
||||
## Guardrails
|
||||
|
||||
- Compaction is survival, not housekeeping. Compact only when a seat is genuinely near its limit, never to
|
||||
"lean" a seat or prepare a starter image; a compacted seat can sound confident while missing the context it needs.
|
||||
- Continue from the map and the files, not from the summary's "next step" alone: a hold placed after the
|
||||
summary was written still binds.
|
||||
- Do not launch a fresh session in place of restoring.
|
||||
- An honest `PARTIAL` with its reason is a correct outcome. Claiming coverage you did not reach is the
|
||||
failure.
|
||||
|
||||
@@ -242,8 +242,9 @@ If you're booting into a new seat in an OpenRig rig:
|
||||
4. **Check what skills you have** — list `.claude/skills/` or
|
||||
`.agents/skills/` in your cwd. Each skill has a frontmatter description
|
||||
that tells you when to reach for it.
|
||||
5. **Check your peers** — `rig capture <peer-session>` to see what they're
|
||||
doing.
|
||||
5. **Check your peers** — `rig ps --nodes` and the queue first (who is up,
|
||||
who holds what). Capture a peer (`rig capture <peer-session>`) only when
|
||||
you actually need to see its screen.
|
||||
6. **Check the transcripts** if you're returning to an in-flight workstream
|
||||
— `rig transcript <session> --tail 100` for recent context.
|
||||
7. **Ask `rig ask <rig> "<question>"`** if you need cross-cutting evidence
|
||||
|
||||
@@ -5,6 +5,8 @@ metadata:
|
||||
cli_surfaces_referenced:
|
||||
- gateway human list
|
||||
- gateway human show
|
||||
- gateway human mode room
|
||||
- gateway human mode decide
|
||||
- queue create
|
||||
- queue transitions
|
||||
- queue block
|
||||
@@ -69,6 +71,28 @@ rig queue create --destination <entityId>@external \
|
||||
--evidence-ref <durable-evidence> --verify --json
|
||||
```
|
||||
|
||||
Before asking a **decision**, check whether the person has a mode on with a
|
||||
decision room: what they said the team may decide for them meanwhile.
|
||||
|
||||
```bash
|
||||
rig gateway human mode room <entityId>
|
||||
```
|
||||
|
||||
If it names a room and your decision is plainly inside their words (and none of
|
||||
their exclusions), decide instead of waiting. Create the ask as above, then
|
||||
record your choice on it straight away:
|
||||
|
||||
```bash
|
||||
rig gateway human mode decide <qitem-id> --application <applicationId> \
|
||||
--choose <question>=<option> --reason "<why>" --reversible # or --irreversible
|
||||
```
|
||||
|
||||
It's recorded as decided on their behalf, never as their answer, the ask
|
||||
closes, and it's in their account when they're back. Say honestly whether it
|
||||
can be undone. A permission prompt or an approval is never decided this way.
|
||||
With no room, a room that doesn't plainly cover it, or any doubt, ask and wait;
|
||||
a recommended option is not a decision.
|
||||
|
||||
An optional `--human-detail-file <path>` supplies one coherent supplemental
|
||||
reply in the same thread. Announce its purpose in the brief; the product also
|
||||
marks that a detail reply follows. The primary must already contain the complete
|
||||
|
||||
@@ -91,7 +91,7 @@ These ship in the OpenRig repo and reach a seat when its profile selects them. T
|
||||
Pod handbooks (load when you're in that pod):
|
||||
- **orchestration-team** — you're orchestrating a rig: dispatching, monitoring, keeping the loop moving.
|
||||
- **development-team** — you're on the dev pod: building and shipping product changes.
|
||||
- **review-team** — you're reviewing: fresh scrutiny, anti-slop, empirical verification.
|
||||
- **review-team** — you're reviewing: fresh scrutiny, anti-slop, grounded findings.
|
||||
- **oversight-team** — you're in an oversight pod: monitor boundaries and route findings without taking over the work.
|
||||
|
||||
Product-management craft (load when shaping/reviewing work):
|
||||
@@ -106,7 +106,7 @@ Product-management craft (load when shaping/reviewing work):
|
||||
### Vendored craft — load when you're coding (ships with upstream provenance)
|
||||
General engineering skills OpenRig ships as vendored copies. Open when the task matches; they carry "modified by OpenRig" provenance.
|
||||
|
||||
- **verification-before-completion** — about to claim done / passing / fixed: run the check and read the output first.
|
||||
- **verification-before-completion** — about to claim done / passing / fixed: have evidence that applies to the candidate you name first.
|
||||
- **systematic-debugging** — debugging: find the root cause before the fix.
|
||||
- **agent-browser** — driving a browser (screenshot / screencast) from an agent.
|
||||
- **frontend-design** — designing frontend / UI.
|
||||
|
||||
@@ -90,6 +90,23 @@ rig queue handoff <qitem-id> \
|
||||
--body-file /tmp/import-report-handoff.md
|
||||
```
|
||||
|
||||
### After a queue write — use the response; read back only when it doesn't show what you need
|
||||
|
||||
A queue write (`create`, `claim`, `update`, `handoff`, `handoff-and-complete`) answers with the row it wrote; a
|
||||
handoff answers with the closed row and its successor. When that answer shows what you need to establish, use it.
|
||||
Read back (`rig queue show <id> --full --json`, or `rig queue transitions <id>`) when it doesn't, for example:
|
||||
|
||||
- the outcome was INDETERMINATE (a transport failure, or a 502 `remote_queue_write_failed`), or the write warned
|
||||
`qitem_body_not_saved` (an existing row came back). Reconcile by the original ID before any retry;
|
||||
- the output was compact or truncated and the field you need isn't in it (the compact receipt shows `bodyBytes`, not
|
||||
the body, and its footer names what it left out);
|
||||
- you need a transition note, a closure or blocker detail, or a successor that the output you saw omits;
|
||||
- you need evidence from downstream of the write: the recipient's wake (`create --verify` waits for it), or its
|
||||
pickup or claim (a later read);
|
||||
- your team's custody rule asks for a separate read-back.
|
||||
|
||||
Don't read back only to see again a field the response already showed you.
|
||||
|
||||
### §1b doctrine — turn ends by passing the ball
|
||||
|
||||
**A turn ends by passing the ball, never by going idle holding the slice waiting
|
||||
@@ -956,12 +973,7 @@ rig auth seats … --runtime codex # seat -> profile registry (metadata
|
||||
|
||||
### Manage subscriptions across a fleet (when the person asks you to)
|
||||
|
||||
**This applies only when both hold:**
|
||||
- the daemon's `provider.subscription_moves` setting is on. It's off by default; the person turns it on with
|
||||
`rig config set provider.subscription_moves true`;
|
||||
- the person has asked you to manage their subscriptions.
|
||||
|
||||
Otherwise, don't take this job on. Installing or upgrading OpenRig appoints no agent, launches no bundle and starts no
|
||||
**This applies only when the person has asked you to manage their subscriptions.** Otherwise, don't take this job on. Installing or upgrading OpenRig appoints no agent, launches no bundle and starts no
|
||||
rotation.
|
||||
|
||||
When a person runs several Claude and Codex subscriptions across machines, the fleet studio bundle's one agent is meant
|
||||
@@ -969,19 +981,19 @@ to keep work running, through the Fleet app. Until that bundle is available, the
|
||||
subscriptions can use this section. If that's you, you decide which subscription or home moves, and when. You decide
|
||||
from:
|
||||
- the usage and assignment readings, and their freshness;
|
||||
- the move record;
|
||||
- your earlier move reports;
|
||||
- the person's standing preferences.
|
||||
|
||||
You say why, and you see the outcome through. OpenRig gives you the facts and the tools; it never decides for you,
|
||||
and there's no threshold to obey.
|
||||
|
||||
**Who decides:**
|
||||
- **The person's operator agent** can ask you for a move, or look at the record. It doesn't make competing moves of
|
||||
- **The person's operator agent** can ask you for a move, or ask what you've moved. It doesn't make competing moves of
|
||||
its own.
|
||||
- **One agent manages subscriptions:** the one the person asked, or the fleet studio's agent once that bundle is
|
||||
available. There's no other fleet-manager role and no automatic manager. Use the commands below directly; no extra
|
||||
hand-off is needed.
|
||||
- **The Observatory is optional:** it can show your moves and readings, but you don't need it to rotate.
|
||||
- **The Observatory is optional:** it can show readings, but you don't need it to rotate.
|
||||
|
||||
**The unit is a Codex home, with every seat on it.** Moving some seats on a shared home to a different account, and
|
||||
moving Claude seats, aren't supported moves yet: say so instead of improvising.
|
||||
@@ -1013,8 +1025,7 @@ moving Claude seats, aren't supported moves yet: say so instead of improvising.
|
||||
--expect-account <the target's Account line>`. `--verify` only checks; it never restarts. Only that check
|
||||
reports `moved`, and anything less is unconfirmed.
|
||||
- **A slow reply isn't a failure:** never restart a seat a second time. Follow up at your next look.
|
||||
5. **Record every move, partial or unconfirmed included,** with `rig provider moves record --file <move.json>`
|
||||
(`--help` shows the shape):
|
||||
5. **Report every move, partial or unconfirmed included,** to whoever asked for it (a queue item to their seat):
|
||||
- the home and machine;
|
||||
- from and to, as labels;
|
||||
- your reason;
|
||||
@@ -1022,10 +1033,8 @@ moving Claude seats, aren't supported moves yet: say so instead of improvising.
|
||||
- each seat's result (`moved`, `unconfirmed` or `unknown`) with its evidence or what's missing;
|
||||
- the peers, for example "not restarted; account unverified".
|
||||
|
||||
A seat marked `moved` needs its `evidence`, and an `unconfirmed` or `unknown` one needs what's `missing`. A home
|
||||
switched with every seat left as a peer is still a move to record, with `seats: []`. A follow-up that confirms an
|
||||
earlier unconfirmed seat records a new move with `supersedes`. Asked "why did this
|
||||
seat move?", answer from `rig provider moves --seat <seat>`. Never put credentials in a record.
|
||||
A home switched with every seat left as a peer is still a move to report. A follow-up that confirms an earlier
|
||||
unconfirmed seat says which report it follows. Never put credentials in a report.
|
||||
6. **When a sign-in is needed:**
|
||||
- Ask the person once, durably: a queue item to their seat, naming the machine and the subscription.
|
||||
- Move nothing onto that subscription until it's done.
|
||||
@@ -1393,9 +1402,10 @@ or `rig add` (one member) when a seat needs an explicit model, a permission poli
|
||||
different agent spec or role profile, per-seat runtime or cwd, or startup files.
|
||||
|
||||
Node-granular managed partial restore (v0.3.4+):
|
||||
- `rig launch <rig> <nodeRef>` relaunches a single seat by logical id or node id through orchestration. `<rig>` is the
|
||||
rig's name or ID; a name shared by more than one active rig stops with the candidate IDs.
|
||||
- `rig launch <rig> --seats <a,b,c>` relaunches a comma-separated subset of seats.
|
||||
- `rig launch <rig> <nodeRef>` launches a single seat that isn't running, by logical id or node id, through orchestration.
|
||||
`<rig>` is the rig's name or ID; a name shared by more than one active rig stops with the candidate IDs. A seat that's
|
||||
already running is left as it is; for a fresh occupant there, use `rig seat launch <seat> --fresh --stop --reason <why>`.
|
||||
- `rig launch <rig> --seats <a,b,c>` launches a comma-separated subset of seats.
|
||||
- `--hold-reason <text>` records a reason for holding non-target seats during the partial launch.
|
||||
- This is a SUPPORTED managed path. The prior `pod_aware_launch_unsupported` dead-end is retired; pod-aware narrow launch now goes through this surface rather than ad-hoc rebuilds.
|
||||
|
||||
|
||||
@@ -29,8 +29,9 @@ without an owner.
|
||||
with the rig appearing dormant.
|
||||
- **Finishing a slice that has a clear next step.** Default-nudge:
|
||||
receiver gets a wake-ping plus the durable queue item.
|
||||
- **Blocked on another agent's work.** Park the qitem with
|
||||
`closure_reason: blocked_on` and the blocker qitem id.
|
||||
- **Blocked on another agent's work.** Use `rig queue block <id> --on <child>`
|
||||
(or `rig queue update <id> --state blocked --blocked-on <child>`). The item
|
||||
stays active and returns to pending when its blocker completes.
|
||||
- **Escalating to the human.** Make the escalation a durable attention
|
||||
item, not just a chat message.
|
||||
|
||||
@@ -53,16 +54,20 @@ human. The qitem state machine enforces this:
|
||||
`pending → in-progress → done` requires `closure_reason` from one of:
|
||||
|
||||
- `handed_off_to` — work continues at a different seat (target = new owner)
|
||||
- `blocked_on` — parked pending another qitem (target = blocker qitem id)
|
||||
- `denied` — receiver rejected the work
|
||||
- `canceled` — sender or receiver withdrew
|
||||
- `no-follow-on` — terminal completion, nothing else needed
|
||||
- `escalation` — kicked up to a higher tier (target = escalation target)
|
||||
- `superseded` — replaced by another qitem (target = successor qitem id)
|
||||
|
||||
Three of those (`handed_off_to`, `blocked_on`, `escalation`) additionally
|
||||
Two of those (`handed_off_to`, `escalation`) additionally
|
||||
require `closure_target`. The daemon enforces this at the domain layer;
|
||||
every surface (CLI, MCP, future UI) inherits the same guarantee.
|
||||
|
||||
`done` is terminal. `closure_reason: blocked_on` is valid only on an active
|
||||
`state=blocked` park record, as used by workflow writers; combining it with
|
||||
`state=done` is rejected. Use the block command above to wait on another qitem.
|
||||
|
||||
**The drafted-park failure (draft ≠ throw).** The rule is about the *actual* pass, not the
|
||||
intention to pass. A turn that ends with a self-instruction **typed into your own prompt but left
|
||||
unsent** — a drafted go-ahead, a next-atom note you never sent — has **not** handed off; it has
|
||||
@@ -120,6 +125,7 @@ inverted the default-nudge polarity.
|
||||
- **Scope tags `project:<id>`, `mission:<id>`, `slice:<id>`** on project work, set when you create the row (`--tags`; `create` also takes `--mission` and `--slice`). Tags can't be edited afterwards. A handoff keeps the source row's tags unless you pass `--tags` or `--gate`, either of which replaces them; repeat the scope tags in `--tags` when you use `--gate`.
|
||||
- **Pass work on with `handoff-and-complete`.** It closes your row as done and records the next row as its successor in one step. A `create` followed by `update --state done --closure-reason handed_off_to` records no successor, and the stuck sweep raises a recovery item for it.
|
||||
- **Close what you hold.** A row you claimed ends in a handoff or an `update --state done --closure-reason …`; `rig queue overdue` lists claimed rows past their deadline.
|
||||
- **Use the write's response.** Read the row back only when the response doesn't show what you need (an indeterminate outcome, a field the compact output left out, downstream wake or pickup, a team custody rule): openrig-user, "After a queue write".
|
||||
- **Brief for the model that will read it.** Before handing a peer open-ended work, check which model it runs: `delegating-work`, "Check what kind of agent you're handing it to".
|
||||
|
||||
## Queue-body hygiene (token + parse safety)
|
||||
|
||||
Reference in new issue
Block a user