@openrig/cli 0.2.0 → 0.3.1

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

@@ -0,0 +1,142 @@
+---
+name: openrig-installer
+description: Use when installing or upgrading OpenRig on a host, especially the V0.3.1 upgrade flow which includes the substrate-kernel → daemon-managed-kernel migration ceremony. Covers npm install, rig setup, rig daemon start (auto-boots kernel), and the canonical verification commands. NOT for ordinary kernel operation post-install — use openrig-operator skill for that.
+metadata:
+  openrig:
+    maturity: L2
+    distribution_scope: shipped
+    source_evidence: V0.3.1 slice 05-kernel-rig-as-default IMPLEMENTATION-PRD §8 + OQ-A=B migration-ceremony decision
+---
+
+# OpenRig Installer
+
+This skill teaches the operator agent how to install + upgrade
+OpenRig cleanly. The V0.3.1 upgrade is the one with the migration
+ceremony (substrate kernel → daemon-managed kernel); other upgrades
+follow the same install / setup / start shape with no migration.
+
+## Fresh install
+
+```bash
+npm install -g @openrig/cli
+rig setup
+```
+
+`rig setup` is idempotent — safe to re-run if a step fails. It probes
+host prereqs (tmux present, Node version, writable state path,
+optional cmux), then invokes `rig daemon start` per the L2 factoring
+(OQ-B). The daemon's start path auto-boots the kernel rig per the
+V0.3.1 slice 05 kernel-rig-as-default logic.
+
+## Verification after install
+
+```bash
+rig ps --nodes --rig kernel --json
+```
+
+Should report 4 members (advisor.lead + operator.agent +
+operator.human + queue.worker) all ready. If a runtime is unavailable
+the daemon picks the matching variant (`rig-claude-only.yaml` or
+`rig-codex-only.yaml`); the topology stays the same shape with the
+unavailable runtime omitted from the agent membership.
+
+Entry point for chatting with the rig:
+
+```bash
+rig capture advisor-lead@kernel
+```
+
+Or click the CMUX button on the topology graph in the UI at
+`/topology`.
+
+## V0.3.1 upgrade ceremony (one-time migration)
+
+Operators with a kernel spec stored outside the daemon-managed
+location (any pre-V0.3.1 layout, typically wherever you kept your
+own `rigs/kernel/` directory) must migrate to
+`~/.openrig/specs/rigs/kernel/` as a one-time step during the V0.3.1
+upgrade. The V0.3.1 upgrade IS the migration moment; it's not a
+separate ceremony.
+
+### Migration steps
+
+1. **Snapshot first.** Take a snapshot of the running substrate
+   kernel so the migration is reversible:
+
+   ```bash
+   rig snapshot kernel
+   ```
+
+2. **Stop the substrate kernel** (so the migration doesn't race a
+   running rig):
+
+   ```bash
+   rig down kernel --snapshot
+   ```
+
+3. **Copy your existing kernel spec** into the daemon-managed
+   location:
+
+   ```bash
+   mkdir -p ~/.openrig/specs/rigs/kernel
+   cp -r /path/to/old/kernel-spec/* ~/.openrig/specs/rigs/kernel/
+   ```
+
+4. **Upgrade the CLI + daemon**:
+
+   ```bash
+   npm install -g @openrig/cli@0.3.1
+   rig daemon stop
+   rig daemon start
+   ```
+
+   At this point the new daemon detects `~/.openrig/specs/rigs/kernel.yaml`
+   exists and skips the V0.3.1 builtin-kernel boot (the
+   already-managed-rig branch). The substrate-rooted topology
+   continues to run under daemon management.
+
+5. **Verify** the migrated kernel matches expectations:
+
+   ```bash
+   rig ps --nodes --rig kernel --json
+   ```
+
+6. **Decommission the old copy** (only after verifying the
+   daemon-managed copy works):
+
+   ```bash
+   rm -rf /path/to/old/kernel-spec
+   ```
+
+### If migration fails
+
+The pre-step snapshot is the rollback. `rig restore <snapshot-id>
+--rig kernel` revives the prior topology. Then `npm install -g
+@openrig/cli@0.3.0` rolls the CLI back and you can retry later.
+
+## Operator agent's role in install + upgrade
+
+The operator agent shepherds operators through these steps when the
+user asks "how do I upgrade?" or "what's the V0.3.1 ceremony?". The
+agent reads this skill on demand via `find-skills` — it does not
+need to memorize the steps; it consults the canonical reference
+(this file) and walks the operator through.
+
+## 3-part error remediation
+
+| What failed | Why it matters | Fix |
+|---|---|---|
+| `npm install -g @openrig/cli` permission denied | Global install needs writable npm prefix; macOS Homebrew default is usually writable; some custom Node installs aren't | Either fix the npm prefix permissions or use `sudo npm install -g`; check `npm config get prefix` |
+| `rig setup` host prereq fail | tmux, Node version, or writable state path missing | `rig doctor` lists each missing piece + the install command; run those, retry `rig setup` |
+| `rig daemon start` auth-block error | Neither Claude Code nor Codex authenticated; kernel rig requires at least one | Run `claude auth login` OR `codex login`; then retry `rig daemon start` |
+| `rig daemon start` "kernel already managed" | An existing managed rig named `kernel` exists; the daemon skips builtin-boot per design | This is the expected path after migration — no action needed |
+| `rig ps --rig kernel --json` returns empty | Daemon healthy but no kernel rig managed; likely the migration step copied content but did not boot | `rig up kernel` from inside `~/.openrig/specs/rigs/kernel/`; or invoke the daemon's cold-boot path explicitly |
+
+## What this skill is NOT
+
+- Not the canonical OpenRig command surface; that lives in the
+  `openrig-user` skill.
+- Not the kernel-operating-procedure for post-install daily use;
+  that's `openrig-operator`.
+- Not for project rigs; project rigs install themselves via `rig
+  up <spec>` after the kernel is in place.

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

@@ -8,6 +8,36 @@ description: Use when operating OpenRig with the `rig` CLI and you need the ship
 This is an as-built guide to the shipped `rig` CLI.
 Use current code and `rig ... --help` as ground truth if anything here ever conflicts with older planning docs.
 
+This is not the config-layer or builder guide. Use the substrate control-plane guidance for `rigx`
+and experimental overlays. Use the OpenRig builder guidance when changing OpenRig behavior,
+doctrine, or release posture.
+
+## Runtime-Gated Coordination Primitives
+
+OpenRig v0.2.0 includes the bundled PL-004 Coordination Primitive System: Phase A `rig stream` /
+`rig queue`, Phase B `rig project` / `rig view`, Phase C `rig watchdog`, and Phase D `rig workflow`
+/ `workflow-keepalive`.
+
+Do not confuse package/source truth with active daemon truth. These commands are shipped product
+surfaces in v0.2.0+, but they need a v0.2.0+ daemon and matching SQLite schema at runtime.
+
+Default posture:
+
+- Treat daemon `rig queue`, `rig stream`, `rig project`, `rig view`, `rig watchdog`, and
+  `rig workflow` as the product coordination surfaces when the active daemon is v0.2.0 or newer.
+- **CANONICAL SURFACE NOTE (2026-05-11)**: `rig queue` (daemon-backed SQLite) is the
+  canonical surface for queue routing since the 2026-05-11 host-CLI fix landed. Use
+  `rig queue create / handoff / update / show / list` for all substantive work.
+- Use temporary substrate overlays such as `rigx queue`, `rigx stream`, `rigx project`, and
+  `rigx view-proto` only where the current OpenRig workstream explicitly says that legacy/control
+  layer is still in use. For queue specifically, `rigx queue` is recovery-only fallback;
+  qitems written via `rigx queue` are invisible to daemon-backed reads and break fleet-wide
+  routing discipline.
+- If a daemon-backed coordination command fails, debug the command/runtime/schema edge directly;
+  do not assume the right workaround is to drop back to a config-layer primitive.
+- Do not perform daemon stop/start, production DB copy/mutation, release, publish, or other
+  consequence-boundary actions unless the operator/workstream has granted that specific gate.
+
 ## Core Loop
 
 Most work in OpenRig reduces to this loop:

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

@@ -0,0 +1,153 @@
+---
+name: openrig-user-settings
+description: Use when the user asks an OpenRig agent to read or change OpenRig configuration settings — workspace paths, file allowlists, progress scan roots, daemon port/host, transcripts, or anything stored in ~/.openrig/config.json
+---
+
+# OpenRig User Settings
+
+OpenRig settings live in `~/.openrig/config.json` and are managed via the
+`rig config` CLI family. The agent-editable surface is **CLI shell-out**;
+do NOT write the JSON file directly unless the operator specifically asks
+for raw-text editing (which is handled by the UI Files browser, not by you).
+
+## Read
+
+```bash
+rig config                                # all keys, value + source
+rig config --json                         # JSON: full RiggedConfig
+rig config --json --with-source           # JSON: {key: {value, source, default}}
+rig config get <key>                      # single value
+rig config get <key> --show-source        # value + source on one line
+rig config get <key> --json               # {value, source, default}
+```
+
+Resolution order: **env var > config file > default**. Always use
+`--show-source` (or `--json`) when reporting back to the operator so they
+see *where* the value came from.
+
+## Write
+
+```bash
+rig config set <key> <value>              # set a key
+rig config reset <key>                    # clear one override (revert to default)
+rig config reset                          # delete the whole file
+```
+
+## Initialize a default workspace
+
+```bash
+rig config init-workspace                 # scaffold ~/.openrig/workspace/ with missions + slices
+rig config init-workspace --dry-run       # show what would be created
+rig config init-workspace --root /path    # use a custom root
+rig config init-workspace --force         # overwrite scaffolded files (NOT operator content)
+```
+
+This creates a file-backed Project workspace under the workspace root:
+
+```text
+README.md
+STEERING.md
+missions/<mission-id>/README.md
+missions/<mission-id>/PROGRESS.md
+missions/<mission-id>/slices/<slice-id>/README.md
+progress/
+field-notes/
+specs/
+```
+
+It seeds two starter missions with multiple slices so the Project UI has a
+real mission/slice map out of the box. It is operator-explicit; do NOT run it
+on your own initiative unless the operator asks for workspace initialization
+or repair.
+
+## Common keys
+
+| Key | Type | Purpose |
+|---|---|---|
+| `daemon.port` | number | OpenRig daemon HTTP port (default 7433) |
+| `daemon.host` | string | Daemon bind host (default 127.0.0.1) |
+| `db.path` | string | SQLite DB path (default ~/.openrig/openrig.sqlite) |
+| `transcripts.enabled` | boolean | Whether the daemon writes transcripts |
+| `transcripts.path` | string | Transcripts dir (default ~/.openrig/transcripts) |
+| `workspace.root` | string | Single-root override (default ~/.openrig/workspace) |
+| `workspace.slices_root` | string | Slice discovery root; default `<root>/missions` |
+| `workspace.steering_path` | string | STEERING.md path; default `<root>/STEERING.md` |
+| `workspace.field_notes_root` | string | Field notes dir; default `<root>/field-notes` |
+| `workspace.specs_root` | string | Specs dir; default `<root>/specs` |
+| `files.allowlist` | string | `name:/abs/path,name:/abs/path` — UI Files browser roots |
+| `progress.scan_roots` | string | `name:/abs/path,name:/abs/path` — Progress browse roots |
+
+Resolution order for workspace per-subdir keys: per-subdir override >
+`workspace.root` cascade > built-in default.
+
+## Common operator requests → canonical commands
+
+> **"Make the UI work against an existing workspace layout"**:
+> set the per-subdir workspace overrides explicitly:
+>
+> ```bash
+> rig config set workspace.slices_root /path/to/your/workspace/missions
+> rig config set workspace.steering_path /path/to/your/workspace/STEERING.md
+> rig config set workspace.progress_scan_roots 'work:/path/to/your/workspace,missions:/path/to/your/workspace/missions'
+> rig config set workspace.field_notes_root /path/to/your/workspace/field-notes
+> ```
+>
+> No restart needed for the CLI; for the daemon's reads to pick up
+> changes affecting startup-time wiring (`files.allowlist`,
+> `progress.scan_roots`), restart with `rig daemon restart`.
+
+> **"Initialize a default workspace"**:
+>
+> ```bash
+> rig config init-workspace
+> ```
+
+After initialization, the Project UI expects this mapping:
+
+- `workspace.root` maps to the Project workspace.
+- `workspace.root/missions/<mission-id>` maps to a Project mission.
+- `workspace.root/missions/<mission-id>/slices/<slice-id>` maps to a Project slice.
+
+Queue item bodies or tags should mention the mission id and slice id when the
+work belongs to a slice. That lets the Project Story, Queue, Tests, and
+Topology tabs attach runtime work to the filesystem slice.
+
+> **"Allow the file browser to see X directory"**:
+>
+> ```bash
+> # Append to existing list (operator decides the name token):
+> rig config get files.allowlist --show-source       # check current
+> rig config set files.allowlist 'workspace:/path/to/ws,docs:/path/to/docs'
+> rig daemon restart                                # picks up new roots
+> ```
+
+> **"What's my current setting for X and where does it come from?"**:
+>
+> ```bash
+> rig config get <key> --show-source
+> ```
+
+## When NOT to use this skill
+
+- **Per-rig config** — settings are host-global at v0; per-rig is v0+1.
+- **Secrets / credentials** — the `vault.specialist` managed-app handles
+  secrets. Don't put API keys or tokens in `~/.openrig/config.json`.
+- **Settings sync across hosts** — out of scope at v0.
+
+## Errors you might see
+
+- `Unknown config key "<x>". Valid keys: …` — the key name is wrong.
+  Check the table above; suggest the correct key.
+- `Config file at <path> is malformed. Fix the JSON or reset with: rig config reset` —
+  hand-edit broke the JSON. Operator can `rig config reset` (deletes the
+  whole file) or fix the syntax in the Files browser.
+- `Invalid value for <key>: expected a number/true-false, got "<x>"` —
+  wrong type for a typed key. Reach for the key's type in the table.
+
+## Provenance + safety
+
+- Never write to `~/.openrig/config.json` directly. Use `rig config set`.
+- Don't run `rig config init-workspace` on your own initiative — wait for
+  an operator request.
+- Always cite the resolved source (env / file / default) when reporting
+  values back, so the operator knows whether their change actually took.

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

@@ -0,0 +1,116 @@
+---
+name: rig-lifecycle
+description: Use when reasoning about the rig lifecycle operations family (create / start / stop / resume / restore / snapshot / release / unclaim / destroy), reading or trusting `rig ps` / lifecycle projections after recovery, or designing proof for a lifecycle scenario. Covers the 4 failure modes (auto-restore creates partial rig; projections report healthier than reality; provider auth treated as impl work; resume succeeds for one runtime fails another) plus the restore-honesty rule (failed resume is FAILED loudly — no auto fresh fallback).
+metadata:
+  openrig:
+    stage: factory-approved
+    last_verified: "2026-05-04"
+    distribution_scope: product-bound
+    source_evidence: |
+      Lifecycle Reboot/Recovery Scenario Matrix (Tier 1 complete; Tier 2
+      human-gated). Codex auth-refusal surfaces as attention_required.
+    sibling_skills:
+      - openrig-user
+      - openrig-operator
+      - seat-continuity-and-handover
+    transfer_test: pending
+---
+
+# Rig Lifecycle
+
+The family of operations that **create, start, stop, resume, restore,
+snapshot, release, unclaim, and destroy** OpenRig-managed topologies.
+Includes the user story after reboot: **"bring my work back without
+turning a clean recovery into a cleanup project."**
+
+If lifecycle is brittle, every higher-level primitive inherits that
+brittleness. Queue, workflow, seat continuity, cross-host operation,
+and RSI all assume that rigs and seats can be restored into known
+states.
+
+## Use this when
+
+- Operating `rig up / down / restore / resume / snapshot / release / unclaim / destroy`
+- Reading `rig ps` after a reboot or recovery and deciding what to trust
+- Designing proof for a lifecycle scenario (clean start / warm resume / host reboot / provider auth loss / partial boot / operator recovery)
+- Reasoning about restore-outcome semantics (`resumed` / `rebuilt` / `fresh` / `failed` / `attention_required`)
+- Auditing whether a lifecycle proof is in-process bedrock vs requires real reboot evidence
+
+## Don't use this when
+
+- The operation is single-command and deterministic — use `openrig-user` skill for CLI surface
+- The work is operator-level configuration of OpenRig itself — use `openrig-operator`
+- The work is rig spec authoring — use `openrig-architect`
+
+## Failure modes (4)
+
+1. **Auto-restore creates a partially restored rig that must be cleaned up before real recovery.** Partial restore looks like recovery but isn't; cleanup-before-recovery becomes the actual workload.
+2. **`rig ps` or lifecycle projections report a healthier state than the runtime actually has.** Projections are summaries; the runtime is truth. Don't trust projections silently.
+3. **Provider auth is unavailable after reboot and the system treats that as implementation work** instead of a human/environment decision. Auth issues are environmental; route to human.
+4. **Resume succeeds for one runtime/provider but fails for another scenario that was never tested.** Per-runtime parity assumptions break silently; matrix proof catches them.
+
+## Restore-honesty rule (load-bearing)
+
+**Failed resume is FAILED loudly.** No automatic fresh fallback. Fresh
+launch is **explicit follow-up only.** This is enforced architecturally
+at the daemon level (per `architecture.md` §7 rule 15).
+
+The locked restore-outcome vocabulary:
+
+| Outcome | Meaning |
+|---|---|
+| `resumed` | Native runtime resumed the same conversation |
+| `rebuilt` | New process assembled from artifacts (`session_source: mode: rebuild`) |
+| `fresh` | New process with no prior continuity |
+| `failed` | Restore attempted and failed; no automatic fallback |
+| `attention_required` | Recoverable blocker (provider auth refused, etc.); needs operator action |
+| `n-a` | Not applicable (terminal nodes, etc.) |
+
+Codex auth-refusal returns `attention_required` (recoverable); Claude
+`looksLikeClaudeLoginPrompt` returns `failed/login_required` (terminal).
+Cross-runtime alignment is an open follow-up question.
+
+## Proof standard
+
+Lifecycle proof should include **real reboot or VM-reboot evidence**,
+not only daemon-unit evidence. The minimum useful matrix covers:
+
+| Scenario | What it proves |
+|---|---|
+| Clean start | Boot from spec into known state |
+| Warm resume | `rig down` → `rig up <name>` resumes seats |
+| Host reboot / tmux socket absence | Recovery from lost tmux connection |
+| Provider auth loss | Codex/Claude auth refusal handled honestly |
+| Partial boot / partial failure | Some seats up, some failed; honest reporting |
+| Intentional operator recovery | Operator-initiated restore from snapshot |
+
+Tier 1: in-process bedrock (daemon-unit evidence). Tier 2: real reboot
+or disposable Tart VM. Tier 1 alone is not lifecycle proof; it's
+bedrock.
+
+## Default policy is part of the primitive
+
+**Treat default policy as part of the primitive, not an afterthought.**
+Lifecycle defaults that are too optimistic for the reliability level
+actually proven create silent harm:
+
+- `auto-restore` defaults that mask failure modes
+- Implicit fresh-fallback that hides resume failure
+- Permissive verification that doesn't distinguish honest success from "appeared to work"
+
+## Total-Host Restore Product Rail v2
+
+The rail sequences restore truth into **four rungs**:
+
+- `fully_restored` is a **Rung 3 execution rollup**
+- "fully back" is **reserved for Rung 4 only**
+
+Naming discipline matters. "Fully restored" and "fully back" are
+different claims; don't conflate.
+
+## See also
+
+- `openrig-user` skill — CLI surface for `rig up / down / restore / etc.`
+- `openrig-operator` skill — operator-level discipline for OpenRig itself
+- `seat-continuity-and-handover` skill — occupant-creation modes for restore (`resume` / `rebuild` / `fresh` / `failed`)
+- `openrig/docs/as-built/architecture.md` (product reference doc) — daemon enforcement of restore-honesty rule

package/daemon/specs/agents/shared/skills/pods/development-team/SKILL.md

@@ -115,7 +115,6 @@ The development pod has access to browser automation and structured dogfood test
 
 - **`agent-browser`** — browser automation CLI. Navigate to the daemon UI, snapshot interactive elements, take annotated screenshots, record repro videos. Use `agent-browser open <url>`, `agent-browser snapshot -i`, `agent-browser screenshot --annotate`.
 - **`dogfood`** — structured exploratory testing workflow. Produces a report with screenshots, repro videos, and step-by-step evidence for every finding.
-- **`containerized-e2e`** — Docker-based clean-install testing. Simulates a fresh user environment.
 
 QA typically drives browser and dogfood testing, but both impl and QA should know these tools exist and can use them. When dogfooding UI:
 1. Load `/agent-browser` and `/dogfood`

package/daemon/specs/agents/shared/skills/pods/orchestration-team/SKILL.md

@@ -183,7 +183,7 @@ For destructive operations (git push, rm, daemon stop, npm publish): DO NOT auto
 - After being told to slow down, over-corrects to "wait for permission for everything"
 - Compaction is catastrophic — full context loss, needs preparation
 - After compaction: must re-read ALL skills from disk (skill names survive in system reminders but content is truncated)
-- For Claude compact-in-place, use `claude-compact-in-place` and require marshal acceptance before treating a `RESTORED` claim as real
+- After compaction, require marshal acceptance before treating a `RESTORED` claim as real — quiz the recovered seat on asked-vs-read depth before resuming work
 
 ### Codex agents (QA, peer, R2)
 - Self-manages its own context window — do NOT intervene based on context percentage
@@ -222,7 +222,7 @@ Before any destructive operation: "If this goes wrong, can I undo it?" If no, co
 4. Read your restore file and session log if available
 5. Ask your peer for a quiz to verify your mental model
 
-For Claude Code seats in OpenRig, marshals/orchestrators should use `claude-compact-in-place` for the asked-vs-read-depth audit before accepting recovery. Preserve the Codex boundary: do not intervene on Codex context percentage or apply Claude compact-in-place by default.
+For Claude Code seats in OpenRig, marshals/orchestrators should run an asked-vs-read-depth audit before accepting recovery (quiz the seat on context it claims to have restored). Preserve the Codex boundary: do not intervene on Codex context percentage or apply Claude compact-in-place by default.
 
 ## What you do not do
 

package/daemon/specs/agents/shared/skills/process/agent-browser/LOCAL-INSIGHTS.md

@@ -123,7 +123,7 @@ EVALEOF
 
 ## Authentication: What Actually Works
 
-**`--session-name` (state save/restore) does NOT work for all apps.** It saves cookies and localStorage, but apps using HTTP-only cookies, server-side sessions, or complex auth flows may not persist. Tested and failed on: tbbc (The Big Blue Cloud / localhost:8083).
+**`--session-name` (state save/restore) does NOT work for all apps.** It saves cookies and localStorage, but apps using HTTP-only cookies, server-side sessions, or complex auth flows may not persist. Tested and failed on: example-app-1 (Example Service One / localhost:8083).
 
 **`--profile` (persistent Chrome profile) is the reliable approach.** It preserves everything - cookies, localStorage, IndexedDB, cache, service workers. This is what actually works for real apps.
 
@@ -131,10 +131,10 @@ EVALEOF
 
 | Profile | Service | URL | Command |
 |---------|---------|-----|---------|
-| `tbbc` | The Big Blue Cloud | `http://localhost:8083` | `agent-browser --profile ~/.agent-browser/profiles/tbbc open http://localhost:8083` |
-| `localhost-3000` | Specright Formulate (Clerk auth) | `http://localhost:3000` | `agent-browser --profile ~/.agent-browser/profiles/localhost-3000 open http://localhost:3000` |
-| `localhost-3010-email` | Smart Report Writer (email login) | `http://localhost:3010` | `agent-browser --profile ~/.agent-browser/profiles/localhost-3010-email open http://localhost:3010` |
-| `localhost-3010-google` | Smart Report Writer (Google auth) | `http://localhost:3010` | See Google OAuth note below |
+| `example-app-1` | Example Service One | `http://localhost:8083` | `agent-browser --profile ~/.agent-browser/profiles/example-app-1 open http://localhost:8083` |
+| `localhost-3000` | Example Service Two (Clerk auth) | `http://localhost:3000` | `agent-browser --profile ~/.agent-browser/profiles/localhost-3000 open http://localhost:3000` |
+| `local-app-email-profile` | Example Service Three (email login) | `http://localhost:3010` | `agent-browser --profile ~/.agent-browser/profiles/local-app-email-profile open http://localhost:3010` |
+| `local-app-google-profile` | Example Service Three (Google auth) | `http://localhost:3010` | See Google OAuth note below |
 
 ### Google OAuth Profiles
 
@@ -142,7 +142,7 @@ Google blocks sign-in from the bundled Chromium ("This browser or app may not be
 
 ```bash
 agent-browser \
-  --profile ~/.agent-browser/profiles/localhost-3010-google \
+  --profile ~/.agent-browser/profiles/local-app-google-profile \
   --executable-path "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
   --args "--disable-blink-features=AutomationControlled" \
   open http://localhost:3010

package/daemon/specs/agents/shared/skills/process/agent-browser/OPENRIG.md

@@ -0,0 +1,40 @@
+---
+skill: agent-browser
+openrig-relationship: vendored-supplemented
+---
+
+# OpenRig and this skill
+
+## Origin
+
+- **Upstream**: Vercel agent-browser CLI (https://github.com/vercel/agent-browser)
+- **Vendoring pattern**: `add-supplementary-files`
+- **Last upstream check**: 2026-05-13 (initial relationship declaration)
+
+## How OpenRig uses this skill
+
+OpenRig ships `agent-browser` so any agent dispatched by an OpenRig topology can drive a real browser (snapshots, form fills, screenshots, scraping, web-app testing) without operators having to separately install a browser-automation skill. It's referenced from any agent profile whose role includes web work.
+
+## 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.
+
+| Surface | What changed | Why |
+|---|---|---|
+| `SKILL.md` body | A short "## Local Dev Insights" section was added near the end with an `**IMPORTANT:** Read LOCAL-INSIGHTS.md` pointer. | Without the pointer, agents loading the skill wouldn't know the companion file exists. The pointer is the only structural modification needed for the supplementary pattern to be discoverable. |
+| `LOCAL-INSIGHTS.md` (new sibling, ~189 lines) | Field-tested gotchas, command-compatibility matrices, corrections discovered through hands-on use that the upstream skill doesn't cover. | E.g., not all `get` subcommands accept `@refs` — `get text @e1` works but `get html @e1` fails silently. The compatibility matrix saves agents from the most common confusion class. |
+
+Nothing else in `SKILL.md` diverges from upstream content as of the last upstream check.
+
+## Companion files
+
+- `LOCAL-INSIGHTS.md` — load-bearing supplementary content. The SKILL.md body explicitly points readers here for hands-on gotchas the upstream skill doesn't cover.
+
+## When to re-sync upstream
+
+Watch for new `agent-browser` CLI releases (Vercel). When the command surface changes meaningfully:
+
+1. Re-sync `SKILL.md` body from upstream, preserving the "Local Dev Insights" pointer section.
+2. Update `LOCAL-INSIGHTS.md` compatibility matrix to reflect new behavior (some `get` subcommands may gain `@ref` support, breaking the current matrix).
+3. Bump `last_upstream_check` in `SKILL.md` frontmatter.
+4. Note any structural shape changes in `divergence_notes`.

package/daemon/specs/agents/shared/skills/process/agent-browser/SKILL.md

@@ -2,6 +2,16 @@
 name: agent-browser
 description: Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.
 allowed-tools: Bash(npx agent-browser:*), Bash(agent-browser:*)
+metadata:
+  openrig:
+    vendored_from: "Vercel agent-browser (https://github.com/vercel/agent-browser)"
+    vendoring_pattern: add-supplementary-files
+    last_upstream_check: "2026-05-13 (initial vendoring declaration)"
+    divergence_notes: |
+      Upstream SKILL.md content tracks upstream; a small "Local Dev Insights"
+      pointer section was added near the end of the body to surface the sibling
+      LOCAL-INSIGHTS.md companion file. See OPENRIG.md for the full OpenRig
+      relationship to this skill.
 ---
 
 # Browser Automation with agent-browser

package/daemon/specs/agents/shared/skills/process/brainstorming/OPENRIG.md

@@ -0,0 +1,48 @@
+---
+skill: brainstorming
+openrig-relationship: vendored-modified
+---
+
+# OpenRig and this skill
+
+## Origin
+
+- **Upstream**: Obra Superpowers (https://github.com/obra/superpowers)
+- **Vendoring pattern**: `modify-the-file`
+- **Last upstream check**: 2026-05-13 (diff against plugin source pulled 2026-05-11)
+
+## How OpenRig uses this skill
+
+`brainstorming` is the "intent → design" front of the OpenRig planning chain. Agents use it before any creative or implementation work — to refine user intent into a shareable design doc that downstream skills (`writing-plans`, then `executing-plans`) consume.
+
+## OpenRig-specific modifications
+
+| Surface | Upstream | OpenRig |
+|---|---|---|
+| Visual Companion offer step | Standalone step #2 in the flow — "offer Visual Companion in its own message before clarifying questions" | **Removed.** OpenRig agents typically operate without a separate visual-companion mode; visual design work routes through dedicated design-pod seats. |
+| Spec self-review step | Step #7 — inline self-review for placeholders/contradictions/scope | **Removed.** Self-review is handled at the rig/orchestration layer (driver/guard pattern + review-lead). |
+| User reviews written spec | Step #8 — pause for user to review the spec file | **Removed.** OpenRig's founder-walk and orchestration gates already cover this checkpoint at a higher level. |
+| Spec save path | `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` | `docs/plans/YYYY-MM-DD-<topic>-design.md` (matches OpenRig's `docs/plans/` convention) |
+| Process flow diagram | Includes Visual Companion + Spec self-review nodes | Simplified to remove those nodes; edges rewired |
+
+## Why these modifications (inferred)
+
+- **Multi-platform / multi-step gates removed**: OpenRig's rig-level orchestration (driver → guard → qa, founder-walks) already provides the checkpoint structure that the upstream skill builds inline. Keeping those steps inside the skill double-gates the work.
+- **`docs/plans/` path**: OpenRig's project structure uses `docs/plans/` as the canonical home for design + implementation plan documents (matches `writing-plans` modification — both are co-ordinated).
+
+## Companion files
+
+None.
+
+## When to re-sync upstream
+
+Watch upstream for:
+
+- New phases or checkpoints in the brainstorming flow that OpenRig might want to adopt (rare; the skill is structurally stable in upstream).
+- Changes to the brainstorming-to-writing-plans handoff (must stay coordinated with the `writing-plans` modifications).
+
+When upstream changes:
+
+1. Pull non-conflicting changes into the OpenRig copy.
+2. Preserve the simplified 6-step flow and the `docs/plans/` save path unless founder direction reverses.
+3. Bump `last_upstream_check` in `SKILL.md` frontmatter.

package/daemon/specs/agents/shared/skills/process/brainstorming/SKILL.md

@@ -1,6 +1,17 @@
 ---
 name: brainstorming
 description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
+metadata:
+  openrig:
+    vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
+    vendoring_pattern: modify-the-file
+    last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11)"
+    divergence_notes: |
+      Simplified the process flow. Removed the Visual Companion offer step,
+      the Spec self-review step, and the User-reviews-spec step (those gates
+      are handled at the rig/orchestration layer in OpenRig). Changed plan-
+      doc save path from docs/superpowers/specs/ to docs/plans/.
+      See OPENRIG.md for full divergence details.
 ---
 
 # Brainstorming Ideas Into Designs

package/daemon/specs/agents/shared/skills/process/dogfood/SKILL.md

@@ -2,6 +2,11 @@
 name: dogfood
 description: Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to "dogfood", "QA", "exploratory test", "find issues", "bug hunt", "test this app/site/platform", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams.
 allowed-tools: Bash(agent-browser:*), Bash(npx agent-browser:*)
+metadata:
+  openrig:
+    vendored_from: "Vercel agent-browser ecosystem (https://github.com/vercel/agent-browser)"
+    vendoring_pattern: vendored-as-is
+    last_upstream_check: "2026-05-13 (diff against ~/.agents/skills/dogfood = identical)"
 ---
 
 # Dogfood