@openrig/cli 0.6.5 → 0.6.7

package/daemon/context-packs/skills/applying-a-permission-policy/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: "applying-a-permission-policy"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use before launching a team during agent-guided setup, or when a user asks to configure OpenRig command permissions, reduce repeated native approval prompts, or apply a selected rig/seat permission policy."
 files:

package/daemon/context-packs/skills/claude-compaction-restore/SKILL.md

@@ -91,11 +91,18 @@ You are about to lose every connection you have built. Spend this turn making th
 1. **Think back before writing.** Walk the session and, through your previous map, the windows before it.
    What were the threads? What did you work out about how the pieces fit? What is unfinished? What did you
    decide, and why? What were you about to be wrong about?
-2. **Write the restore map** in your seat folder, not in scratch (scratch can be cleaned while you are
-   compacted): `<topology root>/rigs/<rig>/seats/<seat>/RESTORE-MAP-<UTC yyyymmdd-hhmm>.md`. Derive the
-   folder from `rig whoami --json` and `rig config get topology.root`. **Run `date -u` for the timestamp and
-   every time you write in the map. Do not estimate times**: an estimated time can land before events it
-   describes, as one did in an early run.
+2. **Write the restore map at the exact path named in OpenRig's preparation request.** Follow that
+   request's completion instructions: use your ordinary file-edit tool to write the named `.tmp` file,
+   with the exact completion marker as its last line, then finish and close it. The daemon publishes
+   the completed map atomically; do not run a shell rename or write the final file incrementally.
+   Do not substitute the seat folder or another map. Managed preparation normally publishes
+   `<launch cwd>/.openrig/compaction/preparation/<session>/<attempt>/RESTORE-MAP.md`; its parent
+   compaction folder ignores itself in Git because maps hold private working context. Unknown or
+   unwritable launch directories retain the instance-home fallback named in the request; it may need
+   permission if outside your working directories. When there is **no named path**, use your durable seat
+   folder instead: `<topology root>/rigs/<rig>/seats/<seat>/RESTORE-MAP-<UTC yyyymmdd-hhmm>.md`, derived
+   from `rig whoami --json` and `rig config get topology.root`. **Run `date -u` for the timestamp and every
+   time you write in the map. Do not estimate times**: an estimated time can land before events it describes.
 3. **Open the map with a summary** of 10 to 20 lines: who you are, what you hold, what mattered in this
    window, what is next and who authorizes it, and any hold in force. **Publish that summary as your seat
    recap** too: save it, plus a line naming the map's path, to a file and run
@@ -144,6 +151,15 @@ already leaves you. The edges are the point.
 
 You have facts without connections. Rebuild the connections before you act on anything.
 
+Use the native read tool for file reads throughout restoration. Load `refocusing`
+and consume the current topology and work trace that actually arrived with the
+restore request; do not rerun Python merely to duplicate it. If no current trace
+arrived, name that delivery gap. A packet pointer, compact summary or truncated
+extract is not a full source read. Read required notes and full sources separately
+and complete the restore steps and read-depth audit below; partial reading does
+not establish completed restoration. The earlier acknowledgement-only boundary
+is not a restore request.
+
 1. **Check for a hold first.** Read the restore request, the per-seat instruction file
    (`<OPENRIG_HOME>/compaction/post-compact-extra/<session>.md`, named by your full session such as
    `dev-impl@my-rig.md`) when it exists, the newest row or message from whoever routes your work, and any hold
@@ -162,8 +178,9 @@ You have facts without connections. Rebuild the connections before you act on an
    `rig context work-install` lists what the project declares (intent, context files, skills), so read the pieces
    your task needs. `--deliver` prints them all; when several projects are declared (`--json` lists the ids), name
    one with `--project <id>`.
-4. **Read your own restore map in full**: the newest `RESTORE-MAP-*.md` in your seat folder, which the
-   compaction summary should name. If it points to an earlier map for context you need, read that too.
+4. **Read your own restore map in full** at the exact path named by the preparation request, restore
+   request or compaction summary. Only when none names a path, look for the newest `RESTORE-MAP-*.md`
+   in your seat folder. If the selected map points to an earlier map for context you need, read that too.
 5. **Read down the map's ranked list** to your class's tier line, reading exactly the parts each entry names.
    Then check every row you hold (`rig queue show <id> --full --json`) and anything that may have changed since
    the map was written: merged PRs, new rows, a new hold. The map records what was true when it was written;

package/daemon/context-packs/skills/claude-compaction-restore/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: "claude-compaction-restore"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when a Claude Code session is about to compact, has just compacted, reached its context limit, resumed after /compact, or must rebuild its working picture of a long-running seat from its own restore map, its JSONL transcript and the files it touched."
 files:

package/daemon/context-packs/skills/claude-compaction-restore/scripts/precompact-hook.mjs

@@ -125,6 +125,8 @@ function writeExpectedSentinel(input) {
   fs.mkdirSync(path.dirname(p), { recursive: true });
   fs.writeFileSync(p, `${JSON.stringify({
     version: 1,
+    managedRefocusPending: typeof input.custom_instructions === "string"
+      && input.custom_instructions.trimStart().startsWith("OpenRig managed compaction; wait for the restore request."),
     sessionName: process.env.OPENRIG_SESSION_NAME || process.env.RIGGED_SESSION_NAME || null,
     sessionId: input.session_id || input.sessionId || null,
     transcriptPath: input.transcript_path || null,
@@ -137,6 +139,8 @@ function writePendingRestoreMarker(input, parsed, restoreInstruction, customMess
   fs.mkdirSync(path.dirname(markerPath), { recursive: true });
   const payload = {
     version: 1,
+    managedRefocusPending: typeof input.custom_instructions === "string"
+      && input.custom_instructions.trimStart().startsWith("OpenRig managed compaction; wait for the restore request."),
     createdAt: nowIso(),
     sessionName: process.env.OPENRIG_SESSION_NAME || process.env.RIGGED_SESSION_NAME || null,
     sessionId: input.session_id || input.sessionId || null,

package/daemon/context-packs/skills/core/agent-starters/SKILL.md

@@ -6,15 +6,10 @@ metadata:
     stage: factory-approved
     sibling_skills:
       - claude-compaction-restore
-      - mental-model-ha
-      - scope-recovery
       - session-compaction-and-restore
       - agent-startup-and-context-ingestion
-      - composable-priming-packs
       - session-source-fork
       - seat-continuity-and-handover
-      - claude-compact-in-place
-      - pre-maintenance-agent-preservation
 ---
 
 # Agent Starters
@@ -131,4 +126,3 @@ included, and is that starter still recommended?"
 ## See also
 
 - `session-source-fork` skill — low-level fork primitive that makes native session-based starters possible
-- `composable-priming-packs` skill — manifest-driven layer for producing primed sessions starters reference

package/daemon/context-packs/skills/core/agent-starters/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-starters"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when creating, refreshing, packaging, inspecting, promoting, or deprecating a named per-seat starting point — Agent Starter manifest authoring, the 6-state lifecycle (captured → named → inspectable → used → promoted → deprecated), provenance honesty, and refusal rules. NOT a VM image; a managed starting point composed from agent role + startup context + optional native session source + provenance."
 files:

package/daemon/context-packs/skills/core/agent-startup-and-context-ingestion/SKILL.md

@@ -9,15 +9,10 @@ metadata:
     stage: factory-approved
     sibling_skills:
       - claude-compaction-restore
-      - mental-model-ha
-      - scope-recovery
       - session-compaction-and-restore
       - agent-starters
-      - composable-priming-packs
       - session-source-fork
       - seat-continuity-and-handover
-      - claude-compact-in-place
-      - pre-maintenance-agent-preservation
 ---
 
 # Agent Startup and Context Ingestion
@@ -48,7 +43,7 @@ is scattered or stale, agents execute the wrong thing very efficiently.
 
 - The agent is being created via Agent Starter — the starter's manifest carries startup context
 - The work is artifact-backed mental-model rebuild from a packet — that's `session-compaction-and-restore`
-- The intent is to ship reusable startup content as a skill — that's `writing-skills-for-openrig`
+- The intent is to ship reusable startup content as a skill
 
 ## Failure modes (4)
 
@@ -119,10 +114,8 @@ culture / pod / member / operator) handles the layering.
 ## See also
 
 - `mission-slice-sop` — load when starting assigned mission/slice work; the light artifact and handoff procedure for SPEC.md, NOTES.md, PROGRESS.md and proof. It does not choose the SDLC for the task.
-- `writing-skills-for-openrig` skill — authoring discipline for skill content (what doesn't belong in startup)
 - `forming-an-openrig-mental-model` skill — orientation for new agents
 - `session-compaction-and-restore` skill — restore-time startup ingestion
 - `agent-starters` skill — reusable starter manifests that compose startup context
-- `composable-priming-packs` skill — manifests that produce primed sessions
 - `openrig-operating-model` skill — placement and authority of durable context
 - `openrig/docs/reference/agent-startup-guide.md` (product reference doc; not a skill) — the 7-layer additive startup model + delivery hints

package/daemon/context-packs/skills/core/agent-startup-and-context-ingestion/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-startup-and-context-ingestion"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, \"rig context\" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent)."
 files:

package/daemon/context-packs/skills/core/cross-host-rig-commands/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: "cross-host-rig-commands"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when addressing a registered remote OpenRig host, choosing its transport, or interpreting a cross-host result."
 files:

package/daemon/context-packs/skills/core/human-in-the-loop/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: "human-in-the-loop"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when classifying a slice closeout (auto-continue / human gate / park), routing a real decision to a human, or designing a human queue/dashboard surface. Treats humans as durable network participants with attention surfaces, queues, and decision records — escalation lands as a durable attention item, not a chat message. Approval is NOT required for every clean closeout; the default RSI conveyor continues unless an explicit human gate is reached."
 files:

package/daemon/context-packs/skills/core/messaging-the-human/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: "messaging-the-human"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when project policy calls for a human decision or update, a human delivery is pending or failed, or a reply must resume the right work."
 files:

package/daemon/context-packs/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/context-packs/skills/core/openrig-architect/manifest.yaml

@@ -1,10 +1,10 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-architect"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
-purpose: "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."
+purpose: "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."
 files:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "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."
+    summary: "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."

package/daemon/context-packs/skills/core/openrig-cmux/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-cmux"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when opening OpenRig fleet terminals into cmux — turning a rig, pod, mission, slice, or saved view into live agent tiles via `rig terminal --provider cmux`, or driving cmux on an agent's request. Same OpenRig view semantics as openrig-herdr (the verbs, honest-partial/degrade, read-only cross-rig, scroll/copy, same-size-only duplicates); cmux is the **best-effort** provider (herdr is the default and the proof-gated one). Prefer openrig-herdr unless cmux is specifically wanted."
 files:

package/daemon/context-packs/skills/core/openrig-herdr/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-herdr"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when opening OpenRig fleet terminals as a herdr wall — turning a rig, pod, mission, slice, or saved view into live interactive agent tiles via `rig terminal`, watching another rig read-only, or driving herdr on an agent's request (\"open all my rigs + a mission as views\"). Covers the `rig terminal open|views|status` verbs, the honest-partial/degrade reading of the result, the read-only-by-construction rail for cross-rig views, scroll/copy out of the box, and the same-size-only duplicate-pane "
 files:

package/daemon/context-packs/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.
@@ -57,7 +57,7 @@ These are auto-delivered to every rig; their name+description are already in you
 - **loading-addressable-markdown** — a task names Markdown as `path#h2-slug` or `path#h2-slug/h3-slug` outside the context-pack library.
 - **session-compaction-and-restore** — preparing for, or recovering from, compaction (any runtime). The write- and read-side protocol.
 - **queue-handoff** — you're passing durable work to another seat or ending your turn. The queue is the work ledger, not chat.
-- **refocusing** — a long-running seat may have lost the product outcome, crossed a major boundary, or compacted and needs a fresh path-based trace.
+- **refocusing** — invoke as `refocusing` when a long-running seat may have lost the product outcome, crossed a major boundary, or compacted and needs a fresh path-based trace.
 - **seat-continuity-and-handover** — handing your seat's work across a restart or to another owner.
 - **orienting-to-an-inherited-seat** — you just inherited an existing seat through a planned handover and need to verify its identity, state, and testimony.
 - **retiring-and-inheriting-a-seat** — you're planning a seat transition and need to retire the current occupant into a fresh successor without losing continuity.
@@ -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.

package/daemon/context-packs/skills/core/openrig-skills/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-skills"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when you're operating OpenRig and need the right skill or context for fleet recovery, seat handover, new-seat orientation, a watchdog wake, cross-host reach to an agent on another machine, rig packaging, an OpenRig upgrade, systematic debugging, queue triage, or implementation planning; also use when you don't know what applies or nothing is projected on cold boot."
 files:

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

@@ -37,30 +37,34 @@ 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.
 
 Read the compatible getting-started guide's **Choose your providers** and
-**Kernel startup stays automatic** sections before launch. The choice selects
+**Start the kernel and check its state** sections before launch. The choice selects
 the two project agents. Kernel auto-boot independently uses available
 authenticated accounts, so it may use both even when the project uses one.
 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
-chosen rig name in owner/checker addresses throughout the same task and return.
+chosen rig name in owner/checker addresses (in the starter, `dev-build@<rig>` and
+`dev-review@<rig>`) throughout the same task and return.
 
 ## Establish the working agreement
 
@@ -76,16 +80,21 @@ model turns, but delivered wakes and resumed work **can spend tokens**. Prefer
 an event-driven wait to frequent empty reminders. Wakes cannot answer a user
 question, clear a permission prompt or guarantee progress.
 
-**Ask once before launching or assigning work:** “Allow your agents to run
-OpenRig commands without repeated permission prompts?” **Yes — recommended** /
-**No — keep prompts**. Reuse an existing explicit choice for this scope. Explain
-that this covers all `rig` verbs, including starting/stopping agents and changing
-configuration, at personal project scope unless the user explicitly chooses
-user-wide sessions. It is not global YOLO or permission to invent work.
+**Ask once before launching or assigning work.** For a team with no permission
+policy, seat choice or named Codex profile, recommend keeping the team default:
+Claude team seats run ordinary `rig` commands, project reads and common tests
+without prompts, and lifecycle commands such as `rig up` and `rig down` still
+ask. Only if they want more, offer: “Remember these selected OpenRig commands in
+your native settings for this project?” **Yes** / **No — keep the team default**.
+Reuse an existing explicit choice for this scope.
+Explain that a remembered allowance can cover all `rig` verbs, but Claude team
+seats still ask before lifecycle commands, at personal project scope unless the
+user explicitly chooses user-wide sessions. It is not global YOLO or permission
+to invent work.
 On an actual Yes, follow [Applying a permission policy](#find-the-compatible-permission-guide)
 to add existing native rules, preserve stricter/unrelated settings, and verify
-the target conversation. No or no answer leaves settings alone and continues
-with existing prompts. Remember the explicit choice and exact additions in the
+the target conversation. No or no answer leaves settings alone and keeps the
+team default. Remember the explicit choice and exact additions in the
 existing onboarding context; “Undo the OpenRig command allowances added by this
 setup” removes only those additions. Broader access remains a separate opt-in.
 
@@ -99,8 +108,9 @@ or explicitly reports none. Preserve work and custody before a supported stop.
 
 Choose the team size separately from the coordination method above:
 
-1. **Use the two-agent starter.** Keep the existing owner and independent checker
-   while that pair meets the workload. The owner can implement and coordinate.
+1. **Use the two-agent starter.** Keep its builder (the owner) and independent
+   reviewer (the checker) while that pair meets the workload. The builder can
+   implement and coordinate.
 2. **Add one or two seats to the running rig.** This is the usual next step.
    Follow [Grow the running team](references/worked-example.md#grow-the-running-team)
    for `rig grow` commands, readiness/context/work

package/daemon/context-packs/skills/core/openrig-software-factory/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-software-factory"
-version: "0.6.5"
+version: "0.6.7"
 taxonomy: "skills"
 purpose: "Use when a user wants a continuing software team for a real repository, or has a first OpenRig team and needs a repeatable path for reviewed work and later tasks."
 files: