@openrig/cli 0.6.5 → 0.6.7

package/daemon/context-packs/skills/core/openrig-software-factory/references/worked-example.md

@@ -4,7 +4,7 @@ Use this example to adapt reviewed work to a repository with CSV handling. Choos
 
 This is a concrete CSV-validation example for adaptation, not a requirement that an arbitrary repository become a CSV project or every outcome be split into two slices. This example uses two genuinely dependent slices. Select a real, authorized repository and record its starting commit and existing CSV behavior. If it has no relevant CSV code, choose two dependent changes appropriate to that repository and rewrite the example objectives before execution; ordinary user tasks retain their appropriate size.
 
-For the example only, repository root and work root are the same absolute directory, called `PROJECT_ROOT`. The selected project ID is `csv-tool`, mission is `csv-validation`, and rig is the shipped `first-project`. These are authored example identities, not live discoveries. Resolve existing catalog/config/intent first. Never overwrite a real `project.yaml`, `workspace.yaml`, `SPEC.md`, `AGENTS.md`, or existing mission to install a template. Merge compatible fields deliberately or choose an unused work directory and preserve the existing catalog entries. If using a separate work root, launch seats in the code repository and record both roots in intent/context. Keep `project.yaml` two directories above the mission directory for this compiler path; arbitrary custom mission-root layouts are not established here.
+For the example only, repository root and work root are the same absolute directory, called `PROJECT_ROOT`. The selected project ID is `csv-tool`, mission is `csv-validation`, and rig is the shipped `starter`. These are authored example identities, not live discoveries. Resolve existing catalog/config/intent first. Never overwrite a real `project.yaml`, `workspace.yaml`, `SPEC.md`, `AGENTS.md`, or existing mission to install a template. Merge compatible fields deliberately or choose an unused work directory and preserve the existing catalog entries. If using a separate work root, launch seats in the code repository and record both roots in intent/context. Keep `project.yaml` two directories above the mission directory for this compiler path; arbitrary custom mission-root layouts are not established here.
 
 ## Manual work and the queue loop
 
@@ -16,12 +16,12 @@ in the project's existing files.
 
 When work should outlive a turn, the actual owner verifies its identity and uses
 the queue. In this example, owner/checker addresses are synthetic until verified
-against the real `first-project` team. The task file contains the real outcome,
+against the real `starter` team. The task file contains the real outcome,
 boundary, acceptance and evidence pointers; create it before sending:
 
 ```sh
 rig whoami --json
-rig queue create --destination dev-owner@first-project \
+rig queue create --destination dev-build@starter \
   --body-file ./TASK.md --summary 'Implement the agreed CSV inspection' --json
 rig queue claim <returned-qitem-id> --json
 ```
@@ -29,7 +29,7 @@ rig queue claim <returned-qitem-id> --json
 After implementing and checking the cumulative candidate, the current owner uses:
 
 ```sh
-rig queue handoff <owned-qitem-id> --to dev-check@first-project \
+rig queue handoff <owned-qitem-id> --to dev-review@starter \
   --body-file ./REVIEW-REQUEST.md --json
 ```
 
@@ -86,8 +86,8 @@ permissions, supplies a missing product decision or authorizes more work.
 
 ## Permissions at the point of work
 
-Before the first task, ask the agent to configure your choice: keep prompts,
-remember selected commands, or deliberately select broader access. Use
+Before the first task, ask the agent to configure your choice: keep the team
+default, remember selected commands, or deliberately select broader access. Use
 `rig context get skills/applying-a-permission-policy/SKILL.md`, or the
 [compatible source/package paths](../SKILL.md#find-the-compatible-permission-guide).
 The agent handles setup and verifies the actual conversation; the user need not
@@ -100,7 +100,7 @@ work unattended.
 
 ## Grow the running team
 
-Keep `first-project`'s owner and checker when they are enough. When there is useful
+Keep `starter`'s builder and reviewer when they are enough. When there is useful
 independent work, add one or two seats to that running rig. The example below adds
 two builders; it does not require a larger starter, new Workflow or replacement
 sessions. Use the actual rig name if yours differs.
@@ -112,23 +112,23 @@ general-purpose agent:
 
 ```sh
 rig ps --json
-rig ps --nodes --rig first-project --json
-rig queue list --destination dev-owner@first-project --json
+rig ps --nodes --rig starter --json
+rig queue list --destination dev-build@starter --json
 rig specs show orchestrator --kind agent --json
 rig grow --help
 ```
 
-Set `RIG_ID` to the `rigId` for the running `first-project`, and `PROJECT_ROOT`
+Set `RIG_ID` to the `rigId` for the running `starter`, and `PROJECT_ROOT`
 to the absolute code repository. Verify its existing `dev` pod and choose unused
 member names. When the user has authorized the added capacity and cost, run:
 
 ```sh
 rig grow "$RIG_ID" a b --pod dev --runtime codex --cwd "$PROJECT_ROOT" --json
-rig ps --nodes --rig first-project --json
+rig ps --nodes --rig starter --json
 ```
 
 For one builder, omit `b`. The expected new logical IDs are `dev.a` and `dev.b`,
-with addresses `dev-a@first-project` and `dev-b@first-project`; use the actual
+with addresses `dev-a@starter` and `dev-b@starter`; use the actual
 returned identities. The command adds and launches the named seats.
 
 To put those seats in a **new** pod instead, choose this alternative once, with an
@@ -163,8 +163,8 @@ checks, next owner and stopping condition. Then deliver the context instruction,
 for example for the first builder:
 
 ```sh
-rig send dev-a@first-project "Read $PROJECT_ROOT/SPEC.md and the addressed sources in $PROJECT_ROOT/.openrig/factory/TASK-A.md. Run rig whoami --json and rig queue list --owned --json in your own seat; report your identity, scope and any native readiness/permission blocker. Await the bounded queue assignment."
-rig capture dev-a@first-project
+rig send dev-a@starter "Read $PROJECT_ROOT/SPEC.md and the addressed sources in $PROJECT_ROOT/.openrig/factory/TASK-A.md. Run rig whoami --json and rig queue list --owned --json in your own seat; report your identity, scope and any native readiness/permission blocker. Await the bounded queue assignment."
+rig capture dev-a@starter
 ```
 
 Read the actual reply and pane; resolve startup/login/permission prompts under the
@@ -174,7 +174,7 @@ the coordinator creates the distinct agreed task (or hands off an existing owned
 task instead of duplicating it):
 
 ```sh
-rig queue create --destination dev-a@first-project \
+rig queue create --destination dev-a@starter \
   --body-file "$PROJECT_ROOT/.openrig/factory/TASK-A.md" \
   --summary 'Implement the agreed independent change A' --json
 ```
@@ -190,9 +190,9 @@ working agreement and assigned work, not the seat's name or default agent label.
 
 | Seat in this example | Deliberately agreed responsibility |
 | --- | --- |
-| `dev-owner@first-project` | Initially implements and coordinates; can become the dedicated orchestrator, selecting outcomes, separating tasks, owning integration and retaining next-work custody. |
-| `dev-a@first-project`, `dev-b@first-project` | Implement distinct authorized tasks and return exact candidates/evidence. Neither silently edits the other's files or folds both candidates without integration ownership. |
-| `dev-check@first-project` | Retains independent judgment under the project's review policy. The implementer does not count its own check as independent review. |
+| `dev-build@starter` | Initially implements and coordinates; can become the dedicated orchestrator, selecting outcomes, separating tasks, owning integration and retaining next-work custody. |
+| `dev-a@starter`, `dev-b@starter` | Implement distinct authorized tasks and return exact candidates/evidence. Neither silently edits the other's files or folds both candidates without integration ownership. |
+| `dev-review@starter` | Retains independent judgment under the project's review policy. The implementer does not count its own check as independent review. |
 
 This is one progression, not a required four-seat layout. One extra builder may
 be enough; a different workload may justify a specialist or additional independent
@@ -213,7 +213,7 @@ rewrite the starter or your original authored `rig.yaml`. Save a
 separate live export to an unused user-owned path:
 
 ```sh
-rig export "$RIG_ID" -o "$PROJECT_ROOT/.openrig/factory/first-project-expanded.yaml"
+rig export "$RIG_ID" -o "$PROJECT_ROOT/.openrig/factory/starter-expanded.yaml"
 ```
 
 Inspect the export and reconcile it with your user-owned authored RigSpec, retaining
@@ -326,14 +326,14 @@ lifecycle:
   workflow:
     objective: Add reviewed CSV validation without modifying input data
     target:
-      rig: first-project
+      rig: starter
     entry:
       role: owner
     roles:
       owner:
-        preferred_targets: [dev-owner@first-project]
+        preferred_targets: [dev-build@starter]
       checker:
-        preferred_targets: [dev-check@first-project]
+        preferred_targets: [dev-review@starter]
     context_refs:
       - SPEC.md#intent
       - SPEC.md#acceptance
@@ -457,12 +457,12 @@ Complete initial Markdown bodies are specified below, after those frontmatter bl
 
 | File relative to `PROJECT_ROOT` | Initial headings and bodies |
 | --- | --- |
-| `SPEC.md` | `# CSV tool`; `## Purpose`: “Help a person detect invalid CSV input before an import changes data.” `## Working agreement`: “Preserve existing repository rules, data and unrelated edits. The first-project owner coordinates implementation and continuity; dev-check independently checks the exact cumulative candidate. The user decides unresolved product behavior. Agreed local implementation, regression checks and review need no repeated approval; publication, destructive data changes and new external effects remain outside this task. Read the current queue and mission before acting; record evidence and unresolved facts, not invented completion.” |
+| `SPEC.md` | `# CSV tool`; `## Purpose`: “Help a person detect invalid CSV input before an import changes data.” `## Working agreement`: “Preserve existing repository rules, data and unrelated edits. The starter builder coordinates implementation and continuity; dev-review independently checks the exact cumulative candidate. The user decides unresolved product behavior. Agreed local implementation, regression checks and review need no repeated approval; publication, destructive data changes and new external effects remain outside this task. Read the current queue and mission before acting; record evidence and unresolved facts, not invented completion.” |
 | `missions/csv-validation/SPEC.md` | `# CSV validation`; `## Intent`: “A user can inspect a CSV and receive a useful validation result without changing the input file or imported data. First implement a pure inspection result; then expose it in the existing CLI.” `## Acceptance`: “Missing required headers name every missing column. Valid input passes. The CLI uses the inspection result and its chosen blank-cell rule, returns the repository's documented success/failure status and preserves input bytes. Tests exercise both slices. One independent checker records the exact candidate, commands, results and limits. The owner explains how to try it and preserves next-work custody. No publication.” |
 | `missions/csv-validation/NOTES.md` | `# Decisions`; `## Blank required cells`: “PENDING — the user must decide whether a present required column containing blank cells is rejected or accepted. Slice 01 can report those cells without choosing policy; slice 02 must not guess the CLI rule. Record the user's decision, timestamp and source here.” |
 | `missions/csv-validation/PROGRESS.md` | `# Progress`; `## Current position`: “Planned; no implementation, runtime instance or review result yet. Record the operation key, instance/frontier IDs, current owner, candidate and next action when observed.” |
 | `missions/csv-validation/slices/01-inspect/SPEC.md` | `# Inspect CSV`; `## Intent`: “Add or adapt a pure inspection function using the repository's CSV handling. Return missing required headers and blank required cells with row/column locations; do not modify input or choose the pending CLI blank-cell policy.” `## Acceptance`: “Missing-header, valid-input, quoted-field and blank-cell cases produce the documented result. Input bytes and existing import behavior remain unchanged. Record actual commands and candidate for the cumulative checker.” |
-| `missions/csv-validation/slices/02-cli/SPEC.md` | `# CLI validation`; `## Intent`: “Expose slice 01's inspection result through the existing CLI. Reuse its result rather than implementing a second parser. Resolve `../../NOTES.md#blank-required-cells` with the user before choosing the CLI outcome.” `## Acceptance`: “The CLI names missing columns, applies the recorded blank-cell rule, uses documented exit statuses and preserves input bytes. Focused valid/invalid cases and the existing relevant regression checks pass on the candidate supplied to dev-check.” |
+| `missions/csv-validation/slices/02-cli/SPEC.md` | `# CLI validation`; `## Intent`: “Expose slice 01's inspection result through the existing CLI. Reuse its result rather than implementing a second parser. Resolve `../../NOTES.md#blank-required-cells` with the user before choosing the CLI outcome.” `## Acceptance`: “The CLI names missing columns, applies the recorded blank-cell rule, uses documented exit statuses and preserves input bytes. Focused valid/invalid cases and the existing relevant regression checks pass on the candidate supplied to dev-review.” |
 | Both slices' `PROGRESS.md` | `# Progress`; `## Current position`: “Planned; no implementation or proof claimed. Record the exact candidate, completed checks, open dependency and current queue packet as work proceeds.” |
 | Both slices' `PROOF.md` | `# Proof`; `## Evidence`: “No evidence yet. For each executed check record candidate, command, result, evidence path and limits. The independent checker attributes its own judgment separately from author checks.” |
 
@@ -471,15 +471,15 @@ The CLI implementation interface and check commands are repository-derived facts
 ## Bootstrap, context and refocus
 
 1. **Current agent:** inspect the selected installation, repository instructions and existing project catalog. Use `rig --help`, `rig config get workspace.root`, `rig config get workspace.catalog_path`, `rig config get workspace.slices_root` and `rig workspace doctor` as appropriate. Preview an additive `rig config init-workspace --root <chosen-root> --dry-run` if no work tree exists. That scaffolder does not bind the roots or supply the metadata/lifecycle graph above. When setting up the intended instance, use ordinary config help to bind only the intended instance to the selected workspace/catalog/slices root; preserve other catalog entries. Do not silently point a shared daemon at a different project. Scope creation helpers may write the skeleton, but inspect and complete the actual manifests before compiling.
-2. **Current agent, with the user's existing authority:** follow the public guide's prerequisite and permission choice once, preview `first-project`, plan it with the real code cwd, then deliberately launch it. Derive both live addresses and native readiness. Reuse existing appropriate seats; do not start duplicates just to clear prompts. Daemon/kernel readiness and each native seat's readiness are separate facts.
-3. **Owner and checker:** read the repository instructions and relevant intent; derive their own identity and queue. For example, the owner can run `rig context work-install --project csv-tool --mission csv-validation --slice 01-inspect --deliver --runtime codex --cwd <actual-code-root> --json`; use `02-cli` for the dependent work and give the checker both exact slice addresses. `--deliver` returns composed bytes to its caller: it is not a transport acknowledgment. Do not use `--apply-skills` merely to make this example work. `install.skills: []` adds no private or invented skill requirement; discover applicable public skills normally.
+2. **Current agent, with the user's existing authority:** follow the public guide's prerequisite and permission choice once, preview `starter`, plan it with the real code cwd, then deliberately launch it. Derive both live addresses and native readiness. Reuse existing appropriate seats; do not start duplicates just to clear prompts. Daemon/kernel readiness and each native seat's readiness are separate facts.
+3. **Owner and checker:** read the repository instructions and relevant intent; derive their own identity and queue. For example, the builder can run `rig context work-install --project csv-tool --mission csv-validation --slice 01-inspect --deliver --runtime claude-code --cwd <actual-code-root> --json`; use `02-cli` for the dependent work and give the checker both exact slice addresses. `--deliver` returns composed bytes to its caller: it is not a transport acknowledgment. Do not use `--apply-skills` merely to make this example work. `install.skills: []` adds no private or invented skill requirement; discover applicable public skills normally.
 4. **Bootstrap context delivery:** send the two seats a short instruction naming the exact work root and addressed files to retrieve; obtain their scope/role reaction before assigning implementation. A registered context pack can be sent with `rig send --context <discovered-ref>`; an arbitrary filesystem address is not automatically a context-pack ref. Deliver the actual composed bytes when a receiver cannot retrieve them. Keep instruction delivery separate from queue ownership.
-5. **Minimal durable topology context:** derive `topology.root`, then preserve existing chain files. In a new dedicated example instance, put purpose/root pointers in `LEARNED.md`, the two-seat relationship in `rigs/first-project/LEARNED.md`, and short duties in `rigs/first-project/seats/dev-owner/LEARNED.md` and `.../dev-check/LEARNED.md`. Owner text: “Own the user's bounded outcome, implementation, exact check handoff, result and next-work custody; derive the current packet.” Checker text: “Independently judge the supplied candidate against project/mission/slice acceptance, record evidence and limits, and return judgment without self-assigning broader work.” Rig text points to the user's `SPEC.md#working-agreement` and active mission; instance text points to the configured work root. Do not copy a status roster into these files. Optional pod files and eight-region trees are unnecessary.
+5. **Minimal durable topology context:** derive `topology.root`, then preserve existing chain files. In a new dedicated example instance, put purpose/root pointers in `LEARNED.md`, the two-seat relationship in `rigs/starter/LEARNED.md`, and short duties in `rigs/starter/seats/dev-build/LEARNED.md` and `.../dev-review/LEARNED.md`. Owner text: “Own the user's bounded outcome, implementation, exact check handoff, result and next-work custody; derive the current packet.” Checker text: “Independently judge the supplied candidate against project/mission/slice acceptance, record evidence and limits, and return judgment without self-assigning broader work.” Rig text points to the user's `SPEC.md#working-agreement` and active mission; instance text points to the configured work root. Do not copy a status roster into these files. Optional pod files and eight-region trees are unnecessary.
 6. **Refocus delivery:** use the public `refocus-channel.md` and `chain-file-convention.md`, discovered under the selected instance reference directory. The ordinary hook derives roots and emits pointers at its supported prompt/compaction boundaries; it does not mean an edited file has been read. Ask each seat to run the discovered public refocusing procedure and read the relevant named sources once as part of bootstrap, recording any trace gap. Existing running seats do not inherit shell environment edits. Any explicit `OPENRIG_REFOCUS_WORK_NODE` or content override belongs in an intentionally configured launch context, not a claim that setting it in the sender changed another seat.
 
 ## Deliberate runtime creation and truthful continuation
 
-The **actual owner seat**, after choosing the Workflow path, runs the following commands after context and address checks. The example addresses below are used only after its own `rig whoami --json` confirms `dev-owner@first-project`; an unbound bootstrap shell must not pretend to be that seat. `PROJECT_ROOT` is an ordinary task variable holding the selected absolute work root. Pick and record a unique operation key once, then reuse it after a timeout. Use the following commands for the selected graph:
+The **actual owner seat**, after choosing the Workflow path, runs the following commands after context and address checks. The example addresses below are used only after its own `rig whoami --json` confirms `dev-build@starter`; an unbound bootstrap shell must not pretend to be that seat. `PROJECT_ROOT` is an ordinary task variable holding the selected absolute work root. Pick and record a unique operation key once, then reuse it after a timeout. Use the following commands for the selected graph:
 
 ```sh
 rig workflow compile "$PROJECT_ROOT/missions/csv-validation/mission.yaml" \
@@ -488,7 +488,7 @@ rig workflow compile "$PROJECT_ROOT/missions/csv-validation/mission.yaml" \
 rig workflow instantiate-lifecycle "$PROJECT_ROOT/missions/csv-validation/mission.yaml" \
   --operation-key csv-tool-csv-validation-run-1 \
   --root-objective 'Reviewed CSV validation without changing input data' \
-  --created-by dev-owner@first-project --rig first-project --json
+  --created-by dev-build@starter --rig starter --json
 
 rig workflow operation csv-tool-csv-validation-run-1 --json
 rig workflow continue <returned-instance-id> --json
@@ -500,7 +500,7 @@ At each completed step, the **current packet owner** projects its own result. Ex
 
 ```sh
 rig workflow project --instance <instance-id> --current-packet <inspect-packet> \
-  --exit handoff --actor-session dev-owner@first-project \
+  --exit handoff --actor-session dev-build@starter \
   --result-note 'Inspection contract implemented; exact candidate and checks recorded' \
   --evidence-ref <absolute-slice-01-proof-path> --json
 ```
@@ -511,7 +511,7 @@ For a **real unresolved blank-cell product choice**, ask the user the concrete q
 
 ```sh
 rig workflow project --instance <instance-id> --current-packet <cli-packet> \
-  --exit waiting --actor-session dev-owner@first-project \
+  --exit waiting --actor-session dev-build@starter \
   --blocked-on external:user/blank-required-cells \
   --result-note 'Need the user decision recorded in mission NOTES before selecting CLI behavior' \
   --evidence-ref <absolute-mission-notes-path> --json

package/daemon/context-packs/skills/core/openrig-upgrade/SKILL.md

@@ -239,6 +239,8 @@ host in front of you.
     mechanism; this skill does not rewrite launchers.
 11. Record the observed result, remaining local preservation decisions, and the
     exact rollback runtime and backup.
+12. Read what changed in the new version, `rig context get reference/whats-new.md`,
+    and tell your user anything in it that changes how they work.
 
 ## Stop and hand back when
 

package/daemon/context-packs/skills/core/openrig-upgrade/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-upgrade"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when an agent is preparing or performing an OpenRig CLI/daemon upgrade and must preserve live seats, verify each mutation, or reconcile managed plugin and skill files without overwriting local work."
 files:

package/daemon/context-packs/skills/core/rig-bundles-and-shareable-artifacts/SKILL.md

@@ -97,5 +97,4 @@ every workflow a daemon feature.**
 - `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
-- `composable-priming-packs` skill — bundles can package priming packs
 - `openrig-user` skill — `rig bundle create / inspect / install` CLI surface

package/daemon/context-packs/skills/core/rig-bundles-and-shareable-artifacts/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "rig-bundles-and-shareable-artifacts"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "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."
 files:

package/daemon/context-packs/skills/core/rig-lifecycle/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "rig-lifecycle"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when reasoning about the rig lifecycle operations family (create / start / stop / resume / restore / snapshot / release / unclaim / destroy), reading or trusting `rig ps` / lifecycle projections after recovery, or designing proof for a lifecycle scenario. Covers the 4 failure modes (auto-restore creates partial rig; projections report healthier than reality; provider auth treated as impl work; resume succeeds for one runtime fails another) plus the restore-honesty rule (failed resume is FAIL"
 files:

package/daemon/context-packs/skills/core/session-source-fork/SKILL.md

@@ -7,15 +7,10 @@ metadata:
     stage: factory-approved
     sibling_skills:
       - claude-compaction-restore
-      - mental-model-ha
-      - scope-recovery
       - session-compaction-and-restore
       - agent-startup-and-context-ingestion
       - agent-starters
-      - composable-priming-packs
       - seat-continuity-and-handover
-      - claude-compact-in-place
-      - pre-maintenance-agent-preservation
 ---
 
 # session_source Fork

package/daemon/context-packs/skills/core/session-source-fork/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "session-source-fork"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when authoring a rig spec member or `rig expand` payload that needs to start a new managed seat from a prior runtime conversation source — `session_source: { mode: fork, ref: { kind, value } }`. v1 supports `mode: fork` with `ref.kind: native_id` for Claude and Codex. The new seat persists a NEW post-fork token; the parent token is NEVER written onto the new seat. NOT for restoring an existing seat or for artifact-backed mental-model rebuild."
 files:

package/daemon/context-packs/skills/core/specification-system/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "specification-system"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when authoring rig specs, agent specs, workflow specs, startup/context fragments, operating-mode declarations, or designing the user spec library. Covers the 4 failure modes (spec instantiates topology but not workflow/mode; spec depends on local paths and fails on another host; agents modify specs as one-off files instead of preserving reusable intent; validation proves YAML shape but not whether topology can run) and the validation-vs-runtime-realization distinction."
 files:

package/daemon/context-packs/skills/core/topology-mutation-and-seat-management/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "topology-mutation-and-seat-management"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when changing a rig while it is alive — `rig grow` / `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures."
 files:

package/daemon/context-packs/skills/core/watchdog/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "watchdog"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when configuring `rig watchdog` policies, authoring wake/refocus/alignment-checkpoint messages, or choosing the right intervention level for a stale-owner situation. The 3-level continuity-check stack (wake / refocus / alignment-checkpoint), the discipline that prevents cadence pollution and bureaucracy theater, and the artifact-pool loop-edge pattern for evidence-aware waking."
 files:

package/daemon/context-packs/skills/delegating-work/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "delegating-work"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when you have a task and must decide WHO does it — yourself, a spawned subagent, or another agent in the topology that already holds the context. The rule: how much would a blank slate have to read in to do this correctly? A lot → route to a context-holding agent; a little → subagent; unsure → a real agent or yourself. NOT the mechanics of fanning out (that's dispatching-parallel-agents / subagent-driven-development) — this is the who/whether decision, and the failure mode that makes teams a"
 files:

package/daemon/context-packs/skills/forming-an-openrig-mental-model/SKILL.md

@@ -196,7 +196,7 @@ rig whoami --json         # know who you are
 rig send <session> "msg"  # talk to a peer
 rig capture <session>     # see a peer's terminal
 rig transcript <session>  # read a peer's history
-rig down <rigId>          # snapshot and tear down
+rig down <rigId>          # snapshot and stop every agent; check rig ps first, only when asked
 rig up <rig-name>         # restore from snapshot
 ```
 

package/daemon/context-packs/skills/forming-an-openrig-mental-model/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "forming-an-openrig-mental-model"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when the system around you does not make sense yet: you just booted into a seat and do not know how the pieces fit; someone said rig, pod, seat, fleet, topology, or slice and you are not certain what they mean here; you are unsure what kind of rig you are in or what it is for; you do not know how skills reach you or where context comes from; or you are about to act on a guess about how OpenRig works. Gives the runtime mental model fast, so you stop guessing."
 files:

package/daemon/context-packs/skills/loading-addressable-markdown/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "loading-addressable-markdown"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when a mission, slice, dashboard, or task references Markdown as path#h2-slug or path#h2-slug/h3-slug outside the OpenRig context-pack library."
 files:

package/daemon/context-packs/skills/mission-slice-sop/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "mission-slice-sop"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when starting, building, handing off, restoring, or closing a mission or slice under the default lightweight SDLC."
 files:

package/daemon/context-packs/skills/openrig-operating-model/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-operating-model"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when you do not know WHERE something belongs: you learned a lesson and are unsure which file takes it; you are about to create a new doc, folder, or convention; you are asking \"should this be a skill, a note, or a chain file?\"; you inherited a seat and want to know what SHOULD exist; or you are about to duplicate knowledge that already has a home. Also the trace-to-root: how a seat orients by reading one filename at each level from where it stands up to the fleet."
 files:

package/daemon/context-packs/skills/openrig-user/SKILL.md

@@ -301,7 +301,10 @@ OpenRig v0.3.0 adds `rig agent-image`, `rig context-pack`, `rig workspace`, and
 `rig config init-workspace`. *(0.5.0: the `rig context-pack` alias is retired — the store + compose library is the single `rig context` noun; see "Context packs and paced delivery (0.5.0)".)* It also shifts fresh-user starter guidance toward
 `product-team` for human-directed work and `conveyor` for workflow-oriented
 work. Treat `demo` as legacy/test content unless a task specifically asks for
-the old demo spec.
+the old demo spec. *(0.6.6: the built-in teams are `starter` and `factory`, plus the
+specialist teams `code-review`, `research` and `pm`. `product-team`, `conveyor` and
+`demo` are gone, and `first-project` is starter's old name. `workshop` is a rig
+bundle.)*
 
 OpenRig v0.3.1 adds public package/source surfaces for Plugin Primitive v0,
 Claude Auto-Compaction Policy, migration `040_workflow_specs_diagnostic`,
@@ -327,7 +330,9 @@ before relying on a policy or its default.
 
 Compatibility checks:
 - `rig down` accepts a rig name or id. An ambiguous name matching more than one
-  active rig is refused with matching ids; use the intended id.
+  active rig is refused with matching ids; use the intended id. It ends every
+  agent's session and any work in progress, so check `rig ps --nodes --rig <rig>`
+  and that the person asked; `rig up <rig> --existing` restores it.
 - For queue/view JSON or limit differences, compare the installed command's help,
   the running daemon version and the actual response. A wrapper mismatch is not
   by itself a daemon-health failure, and historical workarounds are not current
@@ -357,8 +362,8 @@ rig start --json             # JSON output for agents
 ```
 
 Framing: `rig start` is the RECOVERY entry point, not the getting-started
-hero. The fresh-user boot hero remains `rig up <starter>` (typically
-`rig up product-team`). Reach for `rig start` after a host reboot, daemon
+hero. The fresh-user boot hero remains `rig up <team>` (typically
+`rig up starter` for a first change, or `rig up factory`). Reach for `rig start` after a host reboot, daemon
 restart, or any "bring my rigs back" moment.
 
 ### `rig reconcile-session` — no-launch adopt of a hand-resumed session

package/daemon/context-packs/skills/openrig-user/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-user"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when a specific `rig` command, subcommand, or flag is already known and you need its exact syntax, JSON shape, defaults, or error meaning. NOT for natural capability discovery, open-ended how-do-I questions, or choosing which OpenRig move applies."
 files:

package/daemon/context-packs/skills/orienting-to-an-inherited-seat/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "orienting-to-an-inherited-seat"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when you have just been primed into an EXISTING seat through a planned handover — a different agent retired and handed you the seat plus its earned context — and you need a world model of what just happened to you. Covers how a handover differs from compaction and from a fresh launch, the inherit-the-seat-not-the-identity rule, treating the handover packet as testimony you verify (and refusing stale ghost prompts, and verifying your OWN identity surfaces), why a seat is a COMPOUNDING LINEAGE"
 files:

package/daemon/context-packs/skills/pm/backlog-capture/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "backlog-capture"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Quickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication."
 files:

package/daemon/context-packs/skills/pm/context-builder/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "context-builder"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Gather and distill context from meetings, competitors, regulatory sources, and internal discussions. Produces background.md for a feature and updates shared context docs when new knowledge is discovered."
 files:

package/daemon/context-packs/skills/pm/exec-summary/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "exec-summary"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document."
 files:

package/daemon/context-packs/skills/pm/office-hours/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "office-hours"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "YC-style product validation using six forcing questions. Pressure-tests a feature idea before it becomes a requirement — ensuring real demand, a clear wedge, and evidence behind assumptions."
 files:

package/daemon/context-packs/skills/pm/plan-review/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "plan-review"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Multi-perspective review of a feature plan or requirements doc before development begins. Evaluates from strategy, design/UX, and engineering angles to catch gaps early."
 files:

package/daemon/context-packs/skills/pm/requirements-writer/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "requirements-writer"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when converting PM intake into a slice SPEC.md with observable acceptance outcomes, explicit scope, and advisory sibling build dependencies."
 files:

package/daemon/context-packs/skills/pm/ui-mockup/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "ui-mockup"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Create UI mockups at three fidelity levels — ASCII wireframes for quick iteration, standalone HTML mockups for delivery with requirements, and live prototypes for interaction testing."
 files:

package/daemon/context-packs/skills/pods/development-team/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "development-team"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when a development pod begins or hands off implementation, QA, or design work."
 files:

package/daemon/context-packs/skills/pods/orchestration-team/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "orchestration-team"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when coordinating assignments, selected review boundaries, or blocked work across a rig."
 files:

package/daemon/context-packs/skills/pods/oversight-team/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "oversight-team"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when you are a seat on the oversight pod (a standing monitor-mode rig that keeps OTHER rigs healthy), configuring or running the drift detectors, or choosing whether to intervene vs escalate. Covers the pull-not-poll posture, the v0 detectors (premature-park, process-drift, off-task, token-burn), the intervention ladder (orchestrator-ping -> refocus -> human escalation), and the cheap+deep model economics. NOT for orchestrating your OWN rig (orchestration-team) and NOT the intervention primi"
 files:

package/daemon/context-packs/skills/pods/review-team/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "review-team"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when assigned a review or when an authored review boundary is reached."
 files:

package/daemon/context-packs/skills/process/agent-browser/OPENRIG.md

@@ -17,7 +17,7 @@ OpenRig ships `agent-browser` so any agent dispatched by an OpenRig topology can
 
 ## OpenRig-specific modifications
 
-This is the canonical example of the **add-supplementary-files** pattern (see `writing-skills-for-openrig` SKILL.md §"Vendored skills"). The upstream skill is kept structurally intact; OpenRig adds a companion file that captures local-use insights without polluting the upstream content.
+This is the canonical example of the **add-supplementary-files** pattern. The upstream skill is kept structurally intact; OpenRig adds a companion file that captures local-use insights without polluting the upstream content.
 
 | Surface | What changed | Why |
 |---|---|---|

package/daemon/context-packs/skills/process/agent-browser/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-browser"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction."
 files:

package/daemon/context-packs/skills/process/context-engineering/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "context-engineering"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when designing, reviewing, or debugging how an agent's context window gets filled, pruned, or shared — choosing what loads at boot versus on demand, sizing an install or an always-loaded file, fixing an agent that drifts, repeats itself, or forgets constraints mid-task, planning compaction or summarization, deciding single-agent versus subagents, engineering handoffs between agents, or picking a tool loadout. NOT for rewording a prompt's tone, choosing which model to pin, or debugging busine"
 files:

package/daemon/context-packs/skills/process/dogfood/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "dogfood"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to \"dogfood\", \"QA\", \"exploratory test\", \"find issues\", \"bug hunt\", \"test this app/site/platform\", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams."
 files:

package/daemon/context-packs/skills/process/frontend-design/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "frontend-design"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics."
 files: