@openrig/cli 0.2.0 → 0.3.1

package/daemon/specs/agents/shared/skills/process/executing-plans/OPENRIG.md

@@ -0,0 +1,56 @@
+---
+skill: executing-plans
+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 (initial relationship declaration)
+
+## How OpenRig uses this skill
+
+This is the canonical "execute a plan that another seat wrote" skill for OpenRig implementation agents. The driver/guard/qa pattern depends on this skill to keep plan-execution checkpointable and reviewable. Without the batch-with-checkpoint structure, the orchestration loop loses its in-flight review surface.
+
+## OpenRig-specific modifications
+
+The skill was restructured from upstream's all-tasks-at-once execution shape into a batch-with-checkpoint shape:
+
+| Aspect | Upstream | OpenRig |
+|---|---|---|
+| Execution unit | All tasks in plan, sequentially | Batch (default 3 tasks per batch) |
+| Reporting cadence | Once at end (after all tasks complete) | Between every batch |
+| Architect-review surface | None inside the skill | Step 3 "Report" + Step 4 "Continue" cycle |
+| Subagent alternative | Suggests `superpowers:subagent-driven-development` as a better choice when subagents are available | **Removed**. OpenRig topologies already supply separate pods for review; the subagent pointer added cognitive overhead with no win. |
+| Stop conditions | "Hit a blocker" | "Hit a blocker **mid-batch**" |
+| Step 5 "Complete Development" | Step 3 in upstream | Renumbered to Step 5 to make room for the batch-and-report cycle |
+
+The `## Integration` section preserves the upstream sub-skill pointers (`using-git-worktrees`, `writing-plans`, `finishing-a-development-branch`) — those are also vendored from obra-superpowers and present in OpenRig under the same names.
+
+## Why these modifications
+
+- **Batch-and-report cadence fits the OpenRig driver/guard/qa rhythm.** Architect feedback is in-the-loop rather than after-the-fact. A driver who reports between batches gives guard + qa room to surface direction corrections before more work compounds the wrong direction.
+- **The subagent-driven-development pointer doesn't fit the OpenRig posture.** OpenRig already provides parallel-pod review via separate seats; routing through subagents is structurally redundant.
+- **"Mid-batch" precision in stop conditions** matches the batch unit. A driver hitting a blocker between tasks should still report — the unit of "stop and ask" is the batch, not the whole plan.
+
+## Companion files
+
+None at the moment.
+
+## When to re-sync upstream
+
+Watch for upstream changes to:
+
+- **Plan-execution discipline** — stop conditions, verification rules, blocker-handling cadence.
+- **The relationship to writing-plans + finishing-a-development-branch** — if upstream changes how these compose, OpenRig should consider whether the new shape is worth adopting.
+
+When upstream changes:
+
+1. Pull non-conflicting changes into the OpenRig copy.
+2. Preserve the batch-with-checkpoint structure unless founder direction reverses.
+3. Re-check that the subagent-alternative pointer hasn't crept back in.
+4. Bump `last_upstream_check` in `SKILL.md` frontmatter.
+5. Note any structural shape changes in `divergence_notes`.

package/daemon/specs/agents/shared/skills/process/executing-plans/SKILL.md

@@ -1,6 +1,16 @@
 ---
 name: executing-plans
 description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
+metadata:
+  openrig:
+    vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
+    vendoring_pattern: modify-the-file
+    last_upstream_check: "2026-05-13 (initial vendoring declaration)"
+    divergence_notes: |
+      Restructured from upstream's all-tasks-at-once execution into batch-with-
+      checkpoint execution (default 3 tasks per batch + report + continue cycle).
+      Removed the upstream suggestion to use superpowers:subagent-driven-development
+      as an alternative. See OPENRIG.md for full divergence details.
 ---
 
 # Executing Plans

package/daemon/specs/agents/shared/skills/process/frontend-design/SKILL.md

@@ -2,6 +2,11 @@
 name: frontend-design
 description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
 license: Complete terms in LICENSE.txt
+metadata:
+  openrig:
+    vendored_from: "Anthropic skills (Apache 2.0; see LICENSE.txt sibling)"
+    vendoring_pattern: vendored-as-is
+    last_upstream_check: "2026-05-13 (diff against ~/.claude/skills/frontend-design = identical)"
 ---
 
 This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

package/daemon/specs/agents/shared/skills/process/systematic-debugging/SKILL.md

@@ -1,6 +1,11 @@
 ---
 name: systematic-debugging
 description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
+metadata:
+  openrig:
+    vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
+    vendoring_pattern: vendored-as-is
+    last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11 = identical)"
 ---
 
 # Systematic Debugging

package/daemon/specs/agents/shared/skills/process/test-driven-development/SKILL.md

@@ -1,6 +1,11 @@
 ---
 name: test-driven-development
 description: Use when implementing any feature or bugfix, before writing implementation code
+metadata:
+  openrig:
+    vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
+    vendoring_pattern: vendored-as-is
+    last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11 = identical)"
 ---
 
 # Test-Driven Development (TDD)

package/daemon/specs/agents/shared/skills/process/using-superpowers/OPENRIG.md

@@ -0,0 +1,48 @@
+---
+skill: using-superpowers
+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
+
+`using-superpowers` is the catalog-aware "always reach for a skill before answering" bootstrap. It's loaded into every OpenRig agent's startup context to enforce the discipline that skills must be invoked through the `Skill` tool (not Read'd directly), and that the agent should pattern-match descriptions against the work at hand before producing free-form output.
+
+## OpenRig-specific modifications
+
+| Surface | Upstream | OpenRig |
+|---|---|---|
+| `<SUBAGENT-STOP>` block | Skip the skill if dispatched as a subagent | **Removed.** OpenRig doesn't use the upstream subagent-dispatch pattern; this directive doesn't fit the rig/pod/seat topology. |
+| Instruction Priority section | 3-tier priority: user > skills > system | **Removed.** OpenRig handles priority at the AgentSpec + agent-startup-content layer, not inside this skill. |
+| Platform-specific sections (Copilot CLI, Gemini CLI) | Each platform gets its own paragraph for how to access skills | **Removed.** OpenRig targets Claude Code + Codex specifically. The Claude Code paragraph is preserved. |
+| Platform Adaptation section | Points to `references/copilot-tools.md` and `references/codex-tools.md` for tool mapping | **Removed.** OpenRig agents don't need the upstream tool-mapping references; the rig spec lists tools directly. |
+
+## Why these modifications (inferred)
+
+- **Topology mismatch**: OpenRig's subagent model is the rig/pod/seat structure, not the upstream's "dispatch a subagent" pattern. The `<SUBAGENT-STOP>` block would silently skip the skill in seats that should be loading it.
+- **OpenRig is opinionated about target runtimes**: Claude Code + Codex are the supported pair. Multi-platform copy adds cognitive overhead without product value for OpenRig users.
+- **Priority lives at the spec layer**: OpenRig's AgentSpec + startup content (role.md, guidance/, CULTURE.md) is where instruction precedence is encoded; baking it into this skill duplicates the layering.
+
+## Companion files
+
+None. (Upstream ships `references/copilot-tools.md` and `references/codex-tools.md` but these reference the upstream Copilot tool surface, not OpenRig's. They are not vendored.)
+
+## When to re-sync upstream
+
+Watch upstream for:
+
+- Changes to the core "always invoke a skill" discipline (the heart of the skill).
+- New platforms upstream supports that OpenRig might also want to support — would need to add a corresponding paragraph here.
+
+When upstream changes:
+
+1. Pull non-conflicting changes into the OpenRig copy.
+2. Do NOT re-introduce the multi-platform sections, SUBAGENT-STOP block, or Instruction Priority section unless founder direction reverses.
+3. Bump `last_upstream_check` in `SKILL.md` frontmatter.

package/daemon/specs/agents/shared/skills/process/using-superpowers/SKILL.md

@@ -1,6 +1,17 @@
 ---
 name: using-superpowers
 description: Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
+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: |
+      Removed multi-platform-specific sections (Copilot CLI, Gemini CLI,
+      Platform Adaptation) — OpenRig targets Claude Code + Codex. Removed
+      the SUBAGENT-STOP block and Instruction Priority section — OpenRig
+      handles those concerns at the rig/agent-spec layer.
+      See OPENRIG.md for full divergence details.
 ---
 
 <EXTREMELY-IMPORTANT>

package/daemon/specs/agents/shared/skills/process/verification-before-completion/SKILL.md

@@ -1,6 +1,11 @@
 ---
 name: verification-before-completion
 description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
+metadata:
+  openrig:
+    vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
+    vendoring_pattern: vendored-as-is
+    last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11 = identical)"
 ---
 
 # Verification Before Completion

package/daemon/specs/agents/shared/skills/process/writing-plans/OPENRIG.md

@@ -0,0 +1,52 @@
+---
+skill: writing-plans
+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
+
+`writing-plans` is the middle step of OpenRig's three-stage implementation flow: `brainstorming` produces the design, `writing-plans` turns the design into a bite-sized task plan, and `executing-plans` (also OpenRig-modified) drives the plan to completion in batches. Driver seats use this skill when authoring plans for guard + qa to review and for downstream drivers to execute.
+
+## OpenRig-specific modifications
+
+| Surface | Upstream | OpenRig |
+|---|---|---|
+| Plan save path | `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md` | `docs/plans/YYYY-MM-DD-<feature-name>.md` (matches OpenRig's `docs/plans/` convention; coordinated with the matching change in `brainstorming`) |
+| Scope Check section | Explicit step to break multi-subsystem specs into sub-project specs | **Removed.** OpenRig's slice + mission decomposition (handled at the orchestration layer) already enforces single-coherence scope per plan. |
+| File Structure section | Explicit step to map files-to-be-created/modified with responsibilities before defining tasks | **Removed.** OpenRig drivers work inside an already-scoped slice; file-decomposition decisions live in the slice spec, not the plan. |
+| Worktree context hint | "If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time." | "This should be run in a dedicated worktree (created by brainstorming skill)." — less explicit cross-skill dependency. |
+| "For agentic workers" plan-header pointer | Suggests `superpowers:subagent-driven-development` (recommended) or `superpowers:executing-plans` | "For Claude: REQUIRED SUB-SKILL: Use `superpowers:executing-plans` to implement this plan task-by-task." Removed the subagent-driven-development pointer (consistent with the `executing-plans` modification). |
+| Step tracking syntax | `- [ ] **Step 1: ...**` (checkbox for TodoWrite tracking) | `**Step 1: ...**` (bare bold; OpenRig drivers use their own task-tracking) |
+
+## Why these modifications (inferred)
+
+- **Path coordination**: `docs/plans/` is OpenRig's canonical home for plan documents. The `brainstorming` skill produces designs at `docs/plans/...-design.md`; `writing-plans` produces plans at `docs/plans/...-feature-name.md`. Same root.
+- **Scope + structure handled higher**: OpenRig's slice spec already constrains scope (one coherent slice) and identifies the touched-file surface. Repeating those checks inside the plan-authoring skill double-gates the work.
+- **No subagent-driven-development pointer**: same reason as the `executing-plans` modification — OpenRig topologies provide parallel-pod review via separate seats; routing through subagents is structurally redundant.
+- **Bare bold step syntax**: OpenRig drivers track progress via the orchestration queue + their own task tooling, not via in-file TodoWrite checkboxes.
+
+## Companion files
+
+None.
+
+## When to re-sync upstream
+
+Watch upstream for:
+
+- Changes to plan structure or task-granularity guidance.
+- Coordination changes with `brainstorming` and `executing-plans` (this skill is the middle of a 3-skill chain; changes to either end may require this skill to follow).
+
+When upstream changes:
+
+1. Pull non-conflicting changes into the OpenRig copy.
+2. Preserve the `docs/plans/` save path and the absence of the Scope Check + File Structure sections unless founder direction reverses.
+3. Re-check that the subagent-driven-development pointer hasn't crept back in.
+4. Bump `last_upstream_check` in `SKILL.md` frontmatter.

package/daemon/specs/agents/shared/skills/process/writing-plans/SKILL.md

@@ -1,6 +1,16 @@
 ---
 name: writing-plans
 description: Use when you have a spec or requirements for a multi-step task, before touching code
+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: |
+      Removed the Scope Check + File Structure sections, the subagent-driven-
+      development sub-skill pointer, and the checkbox-tracking syntax for
+      steps. Changed plan-doc save path from docs/superpowers/plans/ to
+      docs/plans/. See OPENRIG.md for full divergence details.
 ---
 
 # Writing Plans
@@ -107,9 +117,9 @@ After saving the plan, offer execution choice:
 **Which approach?"**
 
 **If Subagent-Driven chosen:**
-- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development
+- Spawn a fresh subagent for each task; code-review the result before merging
 - Stay in this session
-- Fresh subagent per task + code review
+- Pair with whatever subagent-orchestration skill your runtime provides (e.g., the Obra Superpowers plugin ships one if you have that plugin installed)
 
 **If Parallel Session chosen:**
 - Guide them to open new session in worktree

package/daemon/specs/rigs/launch/conveyor/CULTURE.md

@@ -0,0 +1,34 @@
+# Conveyor Culture
+
+Conveyor is the small public starter for learning OpenRig workflow motion.
+It is intentionally ordinary: one intake lead, one planner, one builder, and
+one reviewer moving queued work through a clear handoff path.
+
+## Responsibilities
+
+- Keep every handoff explicit in the queue.
+- Treat queue depth as the backpressure signal.
+- Prefer small packets that can move from intake to review without extra
+  coordination ceremony.
+- Use review feedback to improve the next build packet instead of hiding
+  defects in chat.
+- Close terminal work with honest closure evidence.
+
+## Principles
+
+- The workflow is a teaching rig, not a private release factory.
+- Runtime primitives stay generic: queue, workflow, watchdog, project, proof,
+  and topology surfaces should all make sense without special background.
+- A user should be able to run multiple conveyor packets at once and understand
+  why one station has a deeper queue than another.
+- If a packet is blocked, the owner records the blocker and target instead of
+  silently waiting.
+
+## Operating Notes
+
+- The `conveyor` workflow is the default station pipeline.
+- The `basic-loop` workflow is a slower walkthrough for watching one packet
+  move end to end.
+- The review seat may route follow-up work back to the build seat by ordinary
+  queue handoff when rework is needed. The default workflow pass path moves
+  review to close.

package/daemon/specs/rigs/launch/conveyor/README.md

@@ -0,0 +1,33 @@
+# Conveyor Starter
+
+Conveyor is the OpenRig 0.3.0 starter rig for learning queue handoffs and
+workflow instances.
+
+## Run
+
+```bash
+rig up conveyor
+```
+
+## Workflows
+
+- `conveyor`: station pipeline. Multiple packets can be active at once.
+- `basic-loop`: single-work-item walkthrough for watching one packet move
+  through the same seats.
+
+## Sample Objective
+
+Use this as a first packet:
+
+```text
+Draft a tiny release-readiness checklist for a command-line tool. Keep it to
+five checks and include one verification command.
+```
+
+Expected motion:
+
+1. `intake-lead@conveyor` clarifies the packet and hands it to planning.
+2. `plan-planner@conveyor` turns it into a small plan.
+3. `build-builder@conveyor` drafts the checklist.
+4. `review-reviewer@conveyor` checks the result.
+5. `intake-lead@conveyor` closes the packet with evidence.

package/daemon/specs/rigs/launch/conveyor/rig.yaml

@@ -0,0 +1,72 @@
+version: "0.2"
+name: conveyor
+summary: >
+  Launch-grade starter for OpenRig 0.3.0: a compact station pipeline with
+  intake, planning, build, and review seats. Use it to watch queued work move
+  through handoffs without inheriting any internal release coupling.
+
+culture_file: CULTURE.md
+
+pods:
+  - id: intake
+    label: Intake
+    members:
+      - id: lead
+        agent_ref: "local:../../../agents/conveyor/lead"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: plan
+    label: Planning
+    members:
+      - id: planner
+        agent_ref: "local:../../../agents/conveyor/planner"
+        runtime: codex
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: build
+    label: Build
+    members:
+      - id: builder
+        agent_ref: "local:../../../agents/conveyor/builder"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: review
+    label: Review
+    members:
+      - id: reviewer
+        agent_ref: "local:../../../agents/conveyor/reviewer"
+        runtime: codex
+        profile: default
+        cwd: "."
+    edges: []
+
+edges:
+  - kind: delegates_to
+    from: intake.lead
+    to: plan.planner
+  - kind: delegates_to
+    from: plan.planner
+    to: build.builder
+  - kind: delegates_to
+    from: build.builder
+    to: review.reviewer
+  - kind: delegates_to
+    from: review.reviewer
+    to: build.builder
+  - kind: can_observe
+    from: review.reviewer
+    to: intake.lead
+  - kind: can_observe
+    from: intake.lead
+    to: build.builder
+  - kind: can_observe
+    from: intake.lead
+    to: review.reviewer

package/daemon/specs/rigs/launch/kernel/agents/advisor/lead/agent.yaml

@@ -0,0 +1,35 @@
+name: advisor.lead
+version: "1.0"
+description: Advisor lead — pilots user intent; figures out what to do, asks the operator or queue worker to actually do it
+
+defaults:
+  runtime: claude-code
+
+imports:
+  - ref: local:../../../../../../agents/shared
+
+profiles:
+  default:
+    uses:
+      skills: [openrig-user, openrig-architect, brainstorming, requirements-writer]
+      guidance: [role]
+      subagents: []
+      plugins: []
+      runtime_resources: [shared:claude-default-settings, shared:claude-default-mcp, shared:codex-default-config]
+
+resources:
+  guidance:
+    - id: role
+      path: guidance/role.md
+      target: CLAUDE.md
+      merge: managed_block
+
+startup:
+  files:
+    - path: guidance/role.md
+      delivery_hint: send_text
+      required: true
+    - path: startup/context.md
+      delivery_hint: send_text
+      required: true
+  actions: []

package/daemon/specs/rigs/launch/kernel/agents/advisor/lead/guidance/role.md

@@ -0,0 +1,50 @@
+# Advisor Lead — Role
+
+You are the advisor lead of the user's kernel rig. Your job is to
+pilot the user's intent. The user describes what they want, and you
+figure out what that actually means in terms of OpenRig topology, what
+the trade-offs are, who should do which part of the work, and what to
+hand off.
+
+## You advise; you do not run things
+
+- Bringing rigs up / down / restarting / inspecting health is the
+  operator agent's job. Delegate to `operator.agent@kernel`.
+- Classifying stream items into queue work is the queue worker's job.
+  Delegate to `queue.worker@kernel`.
+- Implementation work happens in project rigs that the operator
+  spins up — you propose those, you do not host them.
+
+## Conversation defaults
+
+- Start by listening. The user often arrives mid-thought; ask one
+  clarifying question, not five.
+- Use the brainstorming skill on novel asks; use requirements-writer
+  to crisp up ambiguous intent into something an implementer rig can
+  pick up.
+- When the user wants to look at their work, route them at the
+  Mission Control / For You / project surfaces in the UI; you don't
+  need to recite content the UI already shows.
+
+## Topology you can reason about
+
+- `openrig-architect` skill is your reference for designing pods +
+  edges + agent profiles for new rigs.
+
+## Surviving compaction
+
+Long advising sessions hit context limits. The discipline is
+externalize-state-to-durable-substrate, not in-context recall:
+recover identity via `rig whoami --json`; recover recent peer
+context via `rig transcript <session> --tail` / `--grep`; recover
+in-flight work via `rig queue list --as <me>`. Hand off load-bearing
+decisions to the queue so a fresh-context advisor can pick them up.
+If the operator has installed a richer compaction-survival skill on
+this host (substrate skill path or `~/.openrig/skills/`), load it
+for more detail.
+
+## When you are uncertain
+
+Say so plainly. Don't invent topology that isn't there; don't promise
+operator the agent will do something without confirming. Honest gaps
+are easier to fix than confident wrong answers.

package/daemon/specs/rigs/launch/kernel/agents/advisor/lead/startup/context.md

@@ -0,0 +1,37 @@
+# Advisor Lead — Startup Context
+
+You just booted as part of the user's kernel rig. The user is reading
+this through their terminal or through the Mission Control UI.
+
+## First action
+
+Introduce yourself in one short paragraph. Tell the user:
+
+1. Who you are (`advisor.lead@kernel`) and what you can do for them
+   today (pilot intent → route to operator or queue worker, propose
+   topology, capture requirements).
+2. That the operator agent is available at `operator.agent@kernel`
+   for "bring my rigs back online" / install / topology mutation
+   work.
+3. That the queue worker is available at `queue.worker@kernel` for
+   classification of stream items.
+
+Don't list every skill; the user can ask if they're curious.
+
+## What you can assume about the user
+
+- The user is on macOS and has Claude Code and/or Codex
+  authenticated (otherwise this rig wouldn't have booted).
+- The user knows OpenRig exists but may not remember every rig name
+  or command. Pointing them at `rig` CLI verbs as they come up is
+  fine; don't dump a manual on them.
+- The user can interrupt you any time. If you're in the middle of a
+  multi-step plan and they ask a different question, pivot cleanly.
+
+## What's already running
+
+- `rig whoami --json` returns your identity.
+- `rig ps --nodes --rig kernel --json` shows the kernel's 4-member
+  topology (3 agents + the human marker).
+- The operator agent can answer "what rigs were running before the
+  last reboot?" from the daemon's persisted state.

package/daemon/specs/rigs/launch/kernel/agents/operator/agent/agent.yaml

@@ -0,0 +1,35 @@
+name: operator.agent
+version: "1.0"
+description: Operator agent — runs OpenRig itself; brings rigs up/down/back-online after reboot; shepherds install + upgrade + migration ceremonies
+
+defaults:
+  runtime: codex
+
+imports:
+  - ref: local:../../../../../../agents/shared
+
+profiles:
+  default:
+    uses:
+      skills: [openrig-user, openrig-operator, rig-lifecycle, systematic-debugging, verification-before-completion, openrig-installer]
+      guidance: [role]
+      subagents: []
+      plugins: []
+      runtime_resources: [shared:claude-default-settings, shared:claude-default-mcp, shared:codex-default-config]
+
+resources:
+  guidance:
+    - id: role
+      path: guidance/role.md
+      target: AGENTS.md
+      merge: managed_block
+
+startup:
+  files:
+    - path: guidance/role.md
+      delivery_hint: send_text
+      required: true
+    - path: startup/context.md
+      delivery_hint: send_text
+      required: true
+  actions: []

package/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md

@@ -0,0 +1,49 @@
+# Operator Agent — Role
+
+You run OpenRig on behalf of the user. You are paired in the operator
+pod with `operator.human@kernel`, who IS the user; you collaborate
+with them and escalate to them when ops decisions need human approval.
+
+## What you do
+
+- Bring rigs up and down (`rig up <spec>`, `rig down <rigId>`).
+- Restart work after a reboot. **The kernel is the only auto-start
+  rig**; other rigs require explicit operator-initiated restart.
+  When the user says "bring my rigs back online":
+  1. List rigs that were running pre-reboot using daemon persisted
+     state (`rig ps --json --all`) and any operator-saved roster.
+  2. Confirm with the user which subset to restart.
+  3. Restart each via `rig up <spec>` (or `rig restore <snapshot>`
+     if a snapshot exists).
+  4. Confirm healthy via `rig ps --nodes --rig <name>`.
+- Inspect topology, transcript, attention queue state, mission
+  control views.
+- Shepherd install / upgrade / migration ceremonies. The
+  `openrig-installer` skill is your reference for the V0.3.1
+  upgrade flow (which includes the substrate-kernel → daemon-managed
+  kernel migration as a one-time ceremony — see openrig-installer
+  for the canonical steps).
+
+## What you do NOT do
+
+- Feature work / code implementation. That belongs in project rigs
+  that you spin up on the user's behalf, not in the kernel.
+- Decisions with significant blast radius (destroying state,
+  force-killing sessions with in-flight work) without human
+  approval. Escalate to `operator.human@kernel`.
+
+## Failure modes to watch
+
+- If a runtime authentication state changes mid-session
+  (`claude auth status` or `codex login status` becomes red), surface
+  this honestly to the user with the fact + reason + fix pattern;
+  don't fall back silently to a half-booted state.
+- If a rig's prior snapshot is missing or corrupted, surface to the
+  user before attempting restoration; offer fresh-start as an
+  explicit alternative.
+
+## When you are uncertain
+
+Ask `operator.human@kernel` via `rig send` or via a qitem. The user
+has context you don't (recent reboots, mid-flight migrations, plans
+to scrap a particular rig).