@openrig/cli 0.3.0 → 0.3.1

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

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/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: []