@openrig/cli 0.6.4 → 0.6.6

package/daemon/specs/agents/shared/skills/core/messaging-the-human/SKILL.md

@@ -79,6 +79,30 @@ never silently clipped. Shorten the brief or related detail as directed. Inspect
 the failed row, then deliberately cancel/replace the authored request if its
 content needs correction; a timeout alone is never a reason to replace it.
 
+A follow-up **update** about earlier work ("the change you approved is merged")
+can post into that item's thread with `--reply-to <earlier-qitem-id>`. It is
+accepted only with `--human-intent update`. Name the item whose thread the
+human saw, such as the parked row, and create the update on the same host as
+that item. Send the update from the seat that owns that thread: the seat that
+parked the row, or the author of the earlier item. A human reply in a thread
+reaches its owning seat, so an update from any other seat posts as a new
+message. It also posts as a new message, rather than being refused, if the
+earlier thread is missing or closed, or while the earlier item still waits on
+the human (a pending human decision, or a row parked on the human), since a
+reply in that thread would answer the decision. In every such case the
+`--verify` result says `threaded: false` with the reason.
+
+A **decision** with a few clear choices can carry `--human-questions-file <path>`:
+a JSON array of 1–4 questions, each
+`{"id", "question", "options": [{"id", "label", "recommended"?}]}` with 2–4
+options (labels up to 75 characters, at most one recommended). Slack shows each
+question as a row of buttons. Each click records that answer on the item, and
+the decision resolves once every question has one. You then receive one reply
+row listing the answers, and the item's `humanAnswers` holds the option ids. The
+human may instead type a reply in the thread; that resolves the decision as
+usual, so read the reply rather than assuming an option was picked. Keep the
+brief complete: the questions add buttons, they do not replace the explanation.
+
 If an existing agent-owned row must wait for a **decision**, block it on the **new live qitem ID**
 (`rig queue block <work-id> --on <human-qitem-id> ...`), not on the human address.
 Completion of the human qitem resumes its dependants. Blocking on the human as

package/daemon/specs/agents/shared/skills/core/openrig-architect/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openrig-architect
-description: Use when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself (use openrig-builder); NOT for ordinary CLI operation of an existing rig (use openrig-user). Covers the full authoring lifecycle from user intent to validated, launchable rig.
+description: Use when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself (use developing-openrig); NOT for ordinary CLI operation of an existing rig (use openrig-user). Covers the full authoring lifecycle from user intent to validated, launchable rig.
 metadata:
   cli_surfaces_referenced:
     - agent validate
@@ -17,7 +17,7 @@ metadata:
     sibling_skills:
       - openrig-user
       - openrig-operator
-      - openrig-builder
+      - developing-openrig
       - openrig-upgrade
       - forming-an-openrig-mental-model
       - ai-dev-workflows
@@ -92,7 +92,7 @@ Every rig is organized into pods — bounded context groups where members share
 **Sizing principles:**
 
 - **Solo agent:** Only when the task is genuinely single-person (quick script, simple question). No rig needed.
-- **Pair (2 agents):** The minimum effective unit for quality work. One does, one verifies. The `implementation-pair` pattern.
+- **Pair (2 agents):** The minimum effective unit for quality work. One does, one verifies. The built-in `starter` team's shape.
 - **Small team (3-5 agents):** Orchestrator + one or two working pods. Good starting point for focused projects.
 - **Full team (6-10 agents):** Multiple bounded contexts with orchestration, development, review, and potentially research or design.
 - **Large team (10-40+ agents):** Complex projects with many concerns. Include pods for development, review, research, documentation, release management, strategy, and any other bounded context the project needs.
@@ -178,7 +178,7 @@ This is where most rigs succeed or fail. The topology is mechanical; the startup
 
 **For serious rigs, also include:**
 4. `startup/context.md` per agent — boot-time grounding (project info, environment details)
-5. Pod SOP skills — how each pod operates (implementation-pair SOP, review-pair SOP, etc.)
+5. Pod SOP skills — how each pod operates (build-pair SOP, review-pair SOP, etc.)
 6. Project-specific documentation in rig-level startup files
 
 **The key principle:** An agent that boots without knowing its role, its team's culture, and its project context will produce generic, unhelpful work. The startup content IS the product value. Invest in it.
@@ -356,7 +356,7 @@ pods:
 **Use when:** The work involves operating software, not just writing code.
 
 ### The Full Product Team
-**7 agents, 3 pods.** The kitchen-sink topology: orchestration pair, development pod (impl + qa + design), review pair. See the `product-team` starter spec for the complete worked example.
+**7 agents, 3 pods.** The kitchen-sink topology: orchestration pair, development pod (impl + qa + design), review pair. See the built-in `factory` spec for the complete worked example.
 
 **Use when:** Full product development with design, implementation, QA, and independent review. Requires strong culture and SOP content to keep all agents engaged.
 

package/daemon/specs/agents/shared/skills/core/openrig-skills/SKILL.md

@@ -13,7 +13,7 @@ You're running inside OpenRig. OpenRig ships a set of **skills** — small docum
 
 ## How OpenRig context works (30 seconds)
 
-Skills are **progressive disclosure**: a skill's *name + description* sit in your context ambiently (the "hot tier"); its *body* loads only when you open it. So you don't pre-read everything — you pattern-match a skill's "when" to your moment, then open just that one. This file is the index over the whole shipped set. (For bounded procedures, open `agent-operated-workflows`; for ongoing agent-backed applications, open `agent-operated-software`.)
+Skills are **progressive disclosure**: a skill's *name + description* sit in your context ambiently (the "hot tier"); its *body* loads only when you open it. So you don't pre-read everything — you pattern-match a skill's "when" to your moment, then open just that one. This file recommends skills from the shipped set. (For bounded procedures, open `agent-operated-workflows`; for ongoing agent-backed applications, open `agent-operated-software`.)
 
 Every row below names **how to reach the skill** — already-hot, or an exact load path. No row is a dead end.
 
@@ -43,7 +43,7 @@ shows an operator — `get` is the agent-facing pull.)
 
 ## The index
 
-> Membership rule (`layout.skills[*].edges.length > 0`): every public skill with at least one product edge in the generated edge layout appears exactly once in this index; no other skill appears.
+> Membership rule (`layout.skills[*].edges.length > 0`): this index recommends skills from the public product edges. Optional procedures remain available through `rig context list` without a recommendation here.
 
 ### Always loaded — the universal spine (open its body when its moment hits)
 These are auto-delivered to every rig; their name+description are already in your context. Open the body when the "when" matches.
@@ -72,7 +72,7 @@ These are auto-delivered to every rig; their name+description are already in you
 These ship in the OpenRig repo and reach a seat when its profile selects them. To use one, select it in your profile's `uses.skills`, or open it directly at `packages/daemon/specs/agents/shared/skills/core/<skill>/SKILL.md`.
 
 - **openrig-software-factory** — a user wants continuing reviewed work: manual/team, queue-only orchestration or an explicit Workflow; add one or two seats to the running starter when useful, with context, ownership, concurrency, spend and permission limits. Load `rig context get skills/core/openrig-software-factory/SKILL.md`.
-- **openrig-architect** — authoring a rig or topology (NOT for changing OpenRig itself — that's `openrig-builder`).
+- **openrig-architect** — authoring a rig or topology (NOT for changing OpenRig itself — that's `developing-openrig`).
 - **openrig-cmux** — driving the `cmux` terminal provider.
 - **openrig-herdr** — opening/managing seat terminals via the default proof-gated provider.
 - **agent-startup-and-context-ingestion** — a seat is booting and ingesting its startup context.
@@ -106,7 +106,6 @@ 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.
 
-- **test-driven-development** — implementing a feature or bugfix: write the failing test first.
 - **verification-before-completion** — about to claim done / passing / fixed: run the check and read the output first.
 - **systematic-debugging** — debugging: find the root cause before the fix.
 - **agent-browser** — driving a browser (screenshot / screencast) from an agent.
@@ -120,6 +119,12 @@ and a useful report to the OpenRig team if you are still stuck. If `rig` won't r
 `daemon/docs/reference/help.md` inside the installed `@openrig/cli` package, or https://www.openrig.dev/help/agents
 (the same text).
 
+## Developing OpenRig itself
+
+If you're changing OpenRig's own source in a clone of the openrig repository, use that repository's
+`developing-openrig` skill (in the checkout's `.claude/skills/` or `.agents/skills/`). It maps the architecture, the
+areas where a small change has a large effect, and which tests to run before a pull request.
+
 ## Need more than what ships here?
 
 This index covers the **shipped** surface. Your project, rig or machine may add its own skills and routers. Check the

package/daemon/specs/agents/shared/skills/core/openrig-software-factory/SKILL.md

@@ -37,13 +37,16 @@ read [references/worked-example.md](references/worked-example.md). Installed cop
 `rig context get skills/core/openrig-software-factory/references/worked-example.md`.
 A roadmap, YAML file or wake does not execute work or authorize a new outcome.
 
-## Choose the first project's providers
-
-Ask which working account(s) the user wants: Claude Code, Codex, or both. Reuse
-an explicit choice and recommend the account they already have working. Use
-`first-project-claude` (two Claude), `first-project` (two Codex), or
-`first-project-mixed` (Claude owner, Codex checker). All share the same task and
-owner/checker culture. Check only selected CLIs/logins; request `claude auth login`
+## Choose the first team and its providers
+
+Ask what the user wants to build and which working account(s) they have: Claude
+Code, Codex, or both. Recommend one of three teams: `starter` (a Claude builder
+and a Codex reviewer, for one bounded change), `workshop` (a lead, a builder, QA
+and a reviewer; a rig bundle installed from its pinned listing) or `factory` (seven
+agents for sustained product work). When the user lacks a provider a team needs,
+write an adapted copy of the team under the same name, as the kernel operator's
+guidance describes; never offer per-provider variants. `first-project` is
+starter's old name. Check only the CLIs/logins the team needs; request `claude auth login`
 or `codex login` once when that selected login is missing. No credential copying,
 unused provider prerequisite or silent model/provider fallback.
 
@@ -55,8 +58,8 @@ Do not add an unused-provider login gate or manual kernel setup to this path.
 An instance-wide provider restriction is a separate request. Preserve an
 existing kernel and working user rigs.
 
-Show the chosen recipe, resolved runtimes/models and exact
-`rig up <starter> --cwd . --plan` / `rig up <starter> --cwd .` commands. Codex seats
+Show the chosen team, resolved runtimes/models and exact
+`rig up <team> --cwd . --plan` / `rig up <team> --cwd .` commands. Codex seats
 retain `gpt-6-astra`; Claude seats use the configured native default without an
 OpenRig model override. Confirm that model with the user and its availability;
 verify the native session's actual model before consequential work. Use the

package/daemon/specs/agents/shared/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
 ```
 
@@ -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/specs/agents/shared/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/specs/agents/shared/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/specs/agents/shared/skills/core/topology-mutation-and-seat-management/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: topology-mutation-and-seat-management
-description: Use when changing a rig while it is alive — `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.
+description: 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.
 metadata:
   cli_surfaces_referenced:
     - adopt
@@ -8,6 +8,7 @@ metadata:
     - bind
     - discover
     - expand
+    - grow
     - launch
     - ps
     - release
@@ -43,13 +44,32 @@ static launch scripts.
 
 ## Use this when
 
-- Adding capacity to a running rig (`rig expand <rig> <pod-fragment-path>`)
+- Adding seats to a running rig (`rig grow <rig-id> <member...>` for the simple case, a fragment with `rig expand` or `rig add` otherwise; see below)
 - Removing capacity (`rig shrink` / `rig remove`)
 - Launching/relaunching a node in a running rig (`rig launch`)
 - Binding a discovered session into an existing logical node (`rig bind`)
 - Adopting a topology + binding live sessions (`rig adopt`)
 - Attaching a shell or agent into a rig node (`rig attach --self`)
 
+## Adding seats: `rig grow` first, a fragment when you need more
+
+`rig grow <rig-id> <member...>` adds one or more seats to a running rig without
+writing YAML. Each seat gets the default agent spec and its `default` profile.
+Check `rig grow --help` on your installed version; at the time of writing:
+
+- `--pod <pod>`: the target pod; inferred when the rig has one pod
+- `--new-pod <pod>`: create a new pod for the seats (not together with `--pod`)
+- `--runtime <runtime>`: one runtime for every named seat (default `claude-code`)
+- `--cwd <path>`: one working directory for every named seat (default: the current directory)
+- `--json`: output for agents
+
+Write a fragment instead when a seat needs something `rig grow` does not set: an
+explicit model, a permission policy, a different agent spec or role profile, a
+per-seat runtime or working directory, or startup files. Use
+`rig expand <rig-id> <pod-fragment-path>` to add a pod, or
+`rig add <rig-id> <pod-namespace> <member-fragment-path>` to add one member to an
+existing pod.
+
 ## Don't use this when
 
 - The rig is being created fresh from scratch — use `rig up` (lifecycle, not mutation)
@@ -89,6 +109,7 @@ adding or removing a seat from replacing its occupant; use
 
 Per `cli-reference.md` v0.2.0:
 
+- `rig grow <rig-id> <member...> [--pod <pod> | --new-pod <pod>] [--runtime <runtime>] [--cwd <path>]` (added after v0.2.0; check `rig grow --help`)
 - `rig expand <rig-id> <pod-fragment-path>` (with optional `session_source`)
 - `rig shrink <rigId> <podRef>`
 - `rig launch <rigId> <nodeRef>`
@@ -114,7 +135,7 @@ unfinished proof obligation is implied by loading this skill.
 
 ## See also
 
-- `openrig-user` skill — CLI surface for `rig expand / shrink / launch / remove / bind / adopt / attach`
+- `openrig-user` skill — CLI surface for `rig grow / expand / shrink / launch / remove / bind / adopt / attach`
 - `seat-scaling-and-specialization` skill — when to add specialized capacity vs generic
 - `seat-continuity-and-handover` skill — replacing an occupant on a stable seat (different shape than topology mutation)
 - `cross-host-rig-commands` skill — cross-host topology mutation (deferred)

package/daemon/specs/agents/shared/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/specs/agents/shared/skills/process/systematic-debugging/SKILL.md

@@ -181,7 +181,6 @@ You MUST complete each phase before proceeding to the next.
    - Automated test if possible
    - One-off test script if no framework
    - MUST have before fixing
-   - Use the `superpowers:test-driven-development` skill for writing proper failing tests
 
 2. **Implement Single Fix**
    - Address the root cause identified
@@ -289,7 +288,6 @@ These techniques are part of systematic debugging and available in this director
 - **`condition-based-waiting.md`** - Replace arbitrary timeouts with condition polling
 
 **Related skills:**
-- **superpowers:test-driven-development** - For creating failing test case (Phase 4, Step 1)
 - **superpowers:verification-before-completion** - Verify fix worked before claiming success
 
 ## Real-World Impact

package/daemon/specs/rigs/focused/{adversarial-review → code-review}/rig.yaml

@@ -1,5 +1,5 @@
 version: "0.2"
-name: adversarial-review
+name: code-review
 summary: >
   Dual independent reviewers with an orchestrator. Each reviewer
   analyzes the code independently, then the orchestrator synthesizes

package/daemon/specs/rigs/focused/pm/CULTURE.md

@@ -0,0 +1,21 @@
+# PM Team Culture
+
+## Mission
+Ship features that solve real customer problems with evidence-backed requirements.
+
+## Working Norms
+
+1. **PM owns the "what" and "why"** — never architecture, estimates, or implementation details.
+2. **Research before you build** — every feature needs context (competitive, regulatory, customer) before requirements are finalized.
+3. **Requirements are literal** — AI agents treat requirements.md as instructions. Be precise. No aspirational content.
+4. **Stay in your lane** — PM writes requirements, researcher gathers context, coder builds prototypes. Escalate when you hit a boundary.
+5. **Write things down** — findings go to reference/, requirements to product-specs/, ideas to the backlog. Nothing lives only in conversation.
+
+## Communication
+- PM agent is the hub. Research and code agents report to PM.
+- Coder can observe researcher output for domain context.
+- When blocked, escalate to PM rather than guessing.
+
+## Mission/slice tracking (the SDLC)
+
+Requirements and delivery are tracked as missions and slices — on-disk markdown the Living Notes UI projects. Load the packaged `mission-slice-sop` skill; the conventions live in `docs/reference/sdlc-conventions.md` (installed: `$OPENRIG_HOME/reference/sdlc-conventions.md`; shipped with the CLI package). PM's leg of the flow: record intent verbatim, author the mini-requirements (the one-glance tier where approval starts) + the proof contract (promised deliverables as observable outcomes; UI deliverables name their planned mockup), then plan-lock with `rig scope slice approve --scope spec`. Proof-lock (`--scope delivery`) is the terminal sign-off after QA's visual compare and `rig proof add … --media` drops (the C1 drop verb).

package/daemon/specs/rigs/focused/{pm-team → pm}/rig.yaml

@@ -1,5 +1,5 @@
 version: "0.2"
-name: pm-team
+name: pm
 culture_file: CULTURE.md
 summary: >
   Product management rig with a PM lead running the 8-step feature flow
@@ -32,7 +32,7 @@ pods:
   - id: dev
     label: Development Support
     members:
-      - id: coder
+      - id: build
         agent_ref: "local:../../../agents/development/implementer"
         runtime: claude-code
         profile: default
@@ -42,10 +42,10 @@ pods:
 edges:
   - kind: delegates_to
     from: pm.lead
-    to: dev.coder
+    to: dev.build
   - kind: can_observe
-    from: dev.coder
+    from: dev.build
     to: pm.researcher
   - kind: escalates_to
-    from: dev.coder
+    from: dev.build
     to: pm.lead

package/daemon/specs/rigs/focused/{research-team → research}/rig.yaml

@@ -1,5 +1,5 @@
 version: "0.2"
-name: research-team
+name: research
 summary: >
   Research topology with an orchestrator coordinating an analyst
   and a synthesizer. The analyst does deep-dive investigation,