@openrig/cli 0.6.5 → 0.6.7

package/daemon/docs/reference/whats-new.md

@@ -0,0 +1,134 @@
+# What changed in OpenRig 0.6.7
+
+This note is for an agent on an install that was just upgraded to 0.6.7. It lists only what behaves differently from
+0.6.6 and what to do about it. For everything OpenRig can do, read the capability map:
+`rig context get onboarding-width/public-what-you-can-do.md`. Each release replaces this file, so
+`rig context get reference/whats-new.md` describes the installed version once the upgraded daemon is running. Without
+a running daemon, read `$OPENRIG_HOME/reference/whats-new.md`. The daemon refreshes that copy when it starts, so right
+after an upgrade it can still hold the previous version's note.
+
+## The OpenRig view is now the handoff
+
+- **Open the view as the step after install or start; don't wait to be asked.** Say you're opening it, run
+  `rig terminal open saved:kernel --window`, then tell the person where it opened. Don't ask "Open the OpenRig view
+  now?", don't wait for a phrase like "show me my agents", and don't finish by printing a command for them to copy. The
+  same command brings their agents back later.
+- **The layout follows the person's terminal width.** On a narrow terminal the operator gets the first tab. On a wide
+  one the dashboard and operator sit side by side and the advisor has its own tab. Inside herdr it opens a focused
+  `openrig kernel` space. A `kernel` view the person saved themselves still wins.
+- **It opens where the caller is.** Terminal gets a window and Ghostty a tab. From Claude Desktop, iTerm or VS Code on a
+  Mac it opens a new Ghostty or Terminal window, and macOS may ask to allow it: mention that clicking Allow is fine only
+  in that case. Over SSH, in CI or with no display, it returns a definite no-window result with the reason. Relay the
+  `run:` command it prints exactly, or give `env -u TMUX tmux attach-session -t '=<canonicalSessionName>'` for the
+  operator.
+- **`rig terminal open <view>` opens a window by default.** Pass `--provider herdr` or `--provider cmux` only to add
+  tiles to a workspace that's already visible. With `--json`, `reusedWorkspace` and `opened: []` mean an existing view
+  was reused, which is success.
+- **The TUI's action is now "Open terminals ▸"** (it was `term ▸`). It opens a desktop window through the same
+  launcher, so the TUI must run on the daemon's desktop.
+- **The `rigs` skill is installed for the person's own agent.** The daemon writes it to `~/.claude/skills/rigs` and
+  `~/.agents/skills/rigs` and refreshes it on every upgrade. It now triggers on any mention of OpenRig, rigs or a team
+  of coding agents. A copy added earlier with skills.sh is left alone and never refreshed.
+
+## Installing and setting up
+
+- **Show the install preview first.** The published install command has a `--dry-run` preview
+  (`rig context get reference/getting-started.md` has both forms). Run the install when the person agrees. If the only
+  failures left are provider sign-ins, have them sign in and continue at "Start the kernel".
+- **If your own harness refuses a tool call while installing,** say so and show the refusal: Claude Code's auto mode can
+  deny calls as well as approve them. Let the person review it in their harness or run that step themselves. A refused
+  call doesn't prove the OpenRig command failed.
+- **`rig setup` installs herdr by default** on macOS and Linux; `--no-herdr` declines it. On a Mac, ask once about
+  Ghostty and on yes rerun `rig setup --ghostty`, keeping `--no-herdr` if it was chosen. Setup no longer installs cmux,
+  and an existing cmux still works. In `--json` output the `cmux_install` step is gone and `herdr_install` and
+  `ghostty_install` appear.
+- **`rig doctor` checks Claude and Codex installs, and a login or configured provider credential,** the way setup does.
+  It exits 1 when either harness is missing or has neither, including one the person doesn't use, so ignore a failure
+  on an unused harness. A pass means a login or configured provider credential is available locally, not that a
+  provider accepts the credential or that an agent can work; no provider request or agent work is tested.
+- **When setting up permissions,** recommend keeping the team default and offer remembered allowances only if the
+  person wants fewer prompts. People slowed by prompts can be pointed to the workshop listing.
+- **Windows users go through WSL2.** For Pi seats there, offer either credential route; a global Pi login still isn't
+  shared with managed seats.
+
+## Fewer prompts
+
+- **In Claude team seats, help on lifecycle commands runs without a prompt.** `rig down --help` and `-h` forms run;
+  the lifecycle actions themselves still ask. Pipelines, command substitutions, redirects and heredocs aren't allowed
+  automatically.
+- **The kernel operator's Claude session runs routine inspection without prompts:** Python, command lookup, `cd`, text
+  helpers and WebFetch. Compound commands and redirects still go to Claude's own permission check.
+- **Managed Codex seats no longer stop at the update menu on start.** Updating Codex is the operator's job: if a Codex
+  seat says its model needs a newer Codex, offer to update Codex and restart that seat, without stopping the team. If a
+  Codex seat shows a model-switch menu near a rate limit, ask the person; don't change the team's model.
+
+## Messages, wakes and Slack
+
+- **A send or wake no longer answers a question that's waiting for a person.** It's refused with
+  `target_needs_input`, and the reason ends `; latest hook, pane unrecognized` when the screen can't be read, even if
+  the hook is minutes old. Read the seat with `rig capture` and get the question answered by whoever should answer it.
+  Don't retry the send.
+- **Slack can post to a channel per rig or seat:** `rig slack channel-map list`, `set <match> <channel>` and
+  `remove <match>`. After a change, invite the app to each channel, run `rig slack verify`, then `rig slack disable`
+  and `rig slack enable` (or restart the daemon). Thread replies still reach the seat in any channel.
+- **A reaction on any part of a Slack ask reaches the seat that asked,** as a task tagged `human-reaction`. Treat it as
+  a signal to interpret, not an answer; the ask stays open. An existing app needs the `reactions:read` scope, the
+  `reaction_added` event and a reinstall, and `rig slack verify` warns when the scope is missing.
+- **A long Slack ask is posted in parts.** If it still can't be posted, you get a task `<ask id>-undeliverable`, tagged
+  `slack-undeliverable`: shorten the ask or link a file for the long part, and send it as a new ask.
+- **Replies sent with "Also send to #channel" now arrive** at the seat that asked, like any other thread reply.
+
+## Running teams
+
+- **`rig down` prints what each agent seemed to be doing before it stops them,** on one stderr line, or "unknown". It's
+  a best-effort snapshot, not a record of what was interrupted. `rig down --host` now exits 2 when the remote teardown
+  reports errors.
+- **Before a handover or compaction, write the seat's recap** with
+  `rig context recap-write --rig <rig> --seat <seat> --file <draft.md>`, not a file tool, so earlier recaps are kept.
+  `rig seat handover <seat>` now works on the same seat again and again; a seat left half-handed-over recovers by
+  running it again.
+- **After a managed compaction, read the `refocusing` skill and consume the current topology and work traces
+  delivered with the restore.** Don't rerun them just to duplicate the delivery; name a missing trace. For a new trace
+  outside that context, use the skill's one-command form. The daemon now installs the skill globally.
+- **The built-in starter and factory leads publish their team's roster** at first start, so `rig roster list` and
+  `rig roster find <topic>` know those teams.
+- **Claiming a parked queue item clears its `blocked_on`.** To park it again on the same gate, run
+  `rig queue update <id> --state blocked` without `--blocked-on`: it reuses the previous gate. Add the usual wake when
+  one is required.
+- **A periodic reminder first fires one interval after you register it,** not immediately.
+- **Workflows:** `rig workflow run` and `rig workflow watch` exit 3 for an aborted instance. When a step that was sent
+  back completes again, the steps that depend on it run again too, including ones that had passed.
+- **Sharing teams:** `rig bundle create` and `rig up <link>` name the bundle after `rig.yaml`'s `name`, and
+  `rig bundle check` names the file in each finding. Submissions go to `mvschwarz/openrig-registry`. The bundle safety
+  check always runs, even with `--skip-version-check --force`.
+- **`rig context add <url> --git` retrieves shallowly by default:** the initial retrieval fetches only the current
+  commit, and a server that refuses shallow retrieval falls back to a full clone with a warning. Use
+  `rig context source update` for later revisions.
+- **Values that used to fail quietly are refused:** a bad `rig chatroom history --since` (fix the value; the room isn't
+  empty) and a `--wake-after` such as `7d` (use hours, for example `168h`).
+- **Pi seats print a `[pi-runner] seat …:` line at start** saying whether a credential was found and, if not, how to
+  fix it. A MiniMax model gets `MINIMAX_API_KEY` when that name is in `recovery.provider_auth_env_allowlist`.
+- **`agents.advisor_session` defaults to the kernel's advisor seat.**
+
+## What to stop doing
+
+- **Stop asking whether to open the OpenRig view, or waiting for a phrase.** Open it after install or start.
+- **Stop using `--provider herdr` for the first view,** and stop pre-warning about macOS prompts from Terminal or
+  Ghostty.
+- **Stop suggesting `--skip-version-check --force` to get past a bundle pre-check failure.** The check always runs.
+- **Stop retrying a send refused with `target_needs_input`.** Get the question answered instead.
+- **Stop telling people to untick "Also send to #channel" when they answer in Slack.** Those replies now arrive.
+
+## Known gaps in 0.6.7
+
+- **Not yet checked on a real machine:** opening the view from Claude Desktop, and the plain-tmux layout without herdr.
+  The full first install from nothing and a Linux run come after this release.
+- **Only one selected lifecycle-help command has been checked in a live Claude session;** source and parser coverage
+  is broader. If a help command still asks, report it.
+- **Codex team seats aren't asked before lifecycle commands yet.**
+- **The send gate trusts the most recently recorded hook.** If hooks are recorded out of order, it can hold a send for
+  a question that's already answered, or miss one that's waiting. `rig capture` shows the real screen.
+- **A Codex seat whose permission request was approved automatically can still read "needs input".**
+- **A launched team still writes its skills into its working folder.**
+- **After a restart, `rig status` shows `Kernel: skipped` whatever the kernel seats' state.** Read them with
+  `rig ps --nodes --rig kernel --full`.

package/daemon/docs/reference/worktree-builds.md

@@ -6,12 +6,12 @@ consume ANOTHER tree's source — a false-green generator, not an inconvenience.
 
 ## What actually happens
 
-`npm install` in a worktree creates `node_modules/@openrig/<pkg>` as a RELATIVE symlink
+A per-worktree install creates `node_modules/@openrig/<pkg>` as a RELATIVE symlink
 (`-> ../../packages/<pkg>`). Relative links resolve against the directory they live in, so:
 
 | setup | `@openrig/daemon` resolves to | verdict |
 |---|---|---|
-| per-worktree `npm install` | that worktree's `packages/daemon` | correct |
+| per-worktree install (`npm ci`) | that worktree's `packages/daemon` | correct |
 | `ln -s <primary>/node_modules node_modules` | **the PRIMARY tree's** `packages/daemon` | **cross-tree** |
 
 Verified by discriminator, not by inference: with a symlinked `node_modules`, a deliberate type
@@ -21,18 +21,24 @@ A worktree can therefore report green against code it does not contain.
 
 ## Rules
 
-1. **Run `npm install` in each worktree** so workspace packages resolve to the
-   worktree's own source.
+1. **Run `npm ci` in each worktree** so workspace packages resolve to the
+   worktree's own source. It installs the locked versions without rewriting
+   `package-lock.json`. Then run `npm run build`, as CI does before the package suites.
 2. **Never symlink `node_modules` from the primary checkout.** It appears to work — builds pass,
    typechecks pass — which is exactly the danger.
 3. **`npx tsc` with no `node_modules` installs an unrelated `tsc` package** and prints
    "This is not the tsc command you are looking for". That message means *no install*, not a
    TypeScript error.
-4. **Build `@openrig/daemon` before typechecking `@openrig/cli`** in a fresh worktree: cli imports
-   `@openrig/daemon/crash-cart` etc., which resolve to daemon's `dist`. Absent dist reads as
+4. **Build `@openrig/daemon` before typechecking `@openrig/cli` or `@openrig/tui`** in a fresh worktree:
+   cli imports `@openrig/daemon/crash-cart` etc. and tui imports `@openrig/daemon/attention`, which resolve
+   to daemon's `dist`. `npm run lint` does this build first. Absent dist reads as
    TS2307 "Cannot find module" plus a cascade of implicit-any — a provisioning artifact, not a
    code defect.
 
+Some cli imports don't depend on `node_modules` at all: `packages/cli/tsconfig.json` maps a few daemon
+subpaths (`crash-cart` among them) straight to the worktree's own `../daemon/dist`. The others resolve through
+`node_modules`, so the rules above still hold.
+
 ## Self-check before trusting any worktree build
 
     [ "$(readlink -f packages/daemon)" = "$(readlink -f node_modules/@openrig/daemon)" ] \

package/daemon/policies/builtin/auto.policy.md

@@ -0,0 +1,24 @@
+---
+source: builtin
+name: auto
+surface: flag
+launch_posture: auto
+policy_schema_version: 1
+description: Claude runs with --permission-mode auto. Codex and Pi launch at the floor.
+---
+
+# Auto (built-in policy — flag surface)
+
+This built-in selects Claude `--permission-mode auto`. Codex and Pi do not have an
+auto mode and launch at their floor (Codex `-s workspace-write` or its named
+profile; Pi `--no-approve`).
+
+**APPLICATION is deterministic, NOT skill-translated.** Auto is a `surface: flag`
+policy: it resolves to a stable launch flag and is applied directly by the runtime
+flag-surface opt-in. The `applying-a-permission-policy` skill does **NOT** translate
+this policy.
+
+**Selection and native enforcement are separate.** A member policy overrides the
+rig policy. A resolved config-surface selection chooses OpenRig's normal launch
+mode and takes precedence over ambient YOLO. Native configuration and managed
+restrictions still matter; recording a policy does not translate config rules.

package/daemon/specs/agents/development/implementer/agent.yaml

@@ -1,6 +1,6 @@
 name: implementer
 version: "1.0"
-description: Implementation agent — writes code following TDD discipline
+description: Implementation agent — implements and verifies coherent changes
 
 defaults:
   runtime: claude-code
@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [development-team, test-driven-development, systematic-debugging, verification-before-completion]
+      skills: [development-team, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/development/qa/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [test-driven-development, development-team, systematic-debugging, verification-before-completion, agent-browser, dogfood]
+      skills: [development-team, systematic-debugging, verification-before-completion, agent-browser, dogfood]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/product-management/pm/agent.yaml

@@ -29,6 +29,16 @@ profiles:
         - shared:codex-default-config
         - shared:claude-activity-hooks
 
+  advisor:
+    uses:
+      skills: [shared:orchestration-team]
+      plugins: [shared:openrig-core]
+      runtime_resources:
+        - shared:claude-default-settings
+        - shared:claude-default-mcp
+        - shared:codex-default-config
+        - shared:claude-activity-hooks
+
 resources:
   guidance:
     - id: role

package/daemon/specs/agents/shared/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/specs/agents/shared/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/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.
@@ -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/specs/agents/shared/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