@openrig/cli 0.5.5 → 0.5.7

package/daemon/specs/agents/shared/skills/core/attention-queue/SKILL.md

@@ -1,264 +0,0 @@
----
-name: attention-queue
-description: Coordination primitive for OpenRig. Per-agent queue files tracking in-flight work with explicit state transitions + handoff semantics + cross-agent composition. Prevents memory-loss drops; surfaces stalls mechanically; closes the feedback loop on handed-off work. Applied liberally by every agent on every kernel-supervised rig; composed views serve human attention, orch pod-load, rig pending-work.
-status: L4-insight
-authored-by: advisor-peer-observer@your-rig
-date: 2026-04-13
-cited-captures:
-  - improvements-inbox.md 2026-04-13T12:54:50Z — broadcast primitive RSI (same batching-by-theme cluster)
-  - Mission 4 cmux stall (2026-04-13 midday) — packet-design + queue-for-cross-rig coordination
-metadata:
-  cli_surfaces_referenced:
-    - chatroom
-    - send
-  openrig:
-    stage: factory-approved
-    sibling_skills:
-      - queue-handoff
-      - workflow-runtime
-      - watchdog
-      - refocus
-      - looping-workflows
-      - intake-routing
-      - human-in-the-loop
-      - dispatching-parallel-agents
-      - subagent-driven-development
-      - control-plane-capabilities
-      - status-not-chat-orchestrator
-      - control-plane-queue
-      - control-plane-watchdog
-      - control-plane-workflows
-      - control-plane-delivery-loop
-      - control-plane-rollout-manager
----
-
-# Attention queue
-
-Use this skill when coordinating work that must survive compaction, cross-agent handoffs, or multi-hour stall detection. Applies when you'd otherwise narrate status to chat or rely on memory for pending items.
-
-## Live protocol override
-
-Current live routing protocol:
-
-- **Known target / explicit owner that should wake now**: `rigx queue handoff <destination> "<body>" --type handoff --urgency soon`
-- **Passive durable assignment without wake-up**: `rigx queue create <destination> "<body>" --type handoff --urgency soon`
-- **Ambiguous or raw intake**: `rigx stream emit "<body>" ...`
-- **Direct dialogue / urgent 1:1 conversation**: `rig send ...`
-- **Summoned 3+ party roundtable**: `rig chatroom ...`
-
-Do not cargo-cult the earlier "stream everything with `--destination`" prototype shape into the
-live control-plane. Stream is now the ambiguous-intake lane, not the universal lane.
-
-## Core shape (minimum-viable discipline)
-
-1. **Author a queue file at** `substrate/shared-docs/rigs/<your-rig>/state/<your-pod>/<your-member>.queue.md`. Same per-pod directory as your session log.
-2. **Every known-target hot-potato work handoff** should arrive via `rigx queue handoff`, not via `rig send`. Use `rigx queue create` only when you intentionally want a passive durable item without wake-up.
-3. **State transitions** (start → promote; finish → complete; stuck → block; hand off → handoff; completed handed-off work notifies source → handoff-complete) are appended to the entry body with timestamp. Never in-place rewrites.
-4. **Cross-rig reads permitted; cross-rig writes forbidden.** Pod-as-authority-boundary doctrine.
-
-### Live command surface note
-
-When the queue control-plane wrapper is installed, treat queue identity as command-resolved, not
-seat-name-guessed:
-
-- `rigx queue whoami` resolves the durable queue that belongs to your current seat
-- `rigx queue list --mine` shows your queue without guessing from member name
-
-This matters for continuity successors such as `lead2` or `lead5`, which may intentionally share
-the canonical `lead.queue.md` file instead of owning a separate `lead2.queue.md` or `lead5.queue.md`.
-
-Known-target direct handoff on the live wrapper:
-
-```bash
-rigx queue handoff orch-lead5@your-rig "Need PM shaping on queue attention loop" --type handoff --urgency soon
-```
-
-Passive durable write without wake-up:
-
-```bash
-rigx queue create orch-lead5@your-rig "Need PM shaping on queue attention loop" --type handoff --urgency soon
-```
-
-## Six operations
-
-| Op | Effect |
-|---|---|
-| append | New entry (state=pending) on inbound request |
-| promote | state=in-progress when you start work |
-| complete | state=done with optional result |
-| block | state=blocked + blocked-on=<id or condition> |
-| handoff | state=handed-off + handed-off-to=<target>/<new-id>; send rig-send with `[queue-handoff:]` prefix to target |
-| handoff-complete | target signals source that handed-off work finished (closes feedback loop) |
-| escalate | walk authority chain when blocked past tier threshold |
-| defer / drop | push-to-later or drop-with-rationale |
-
-## When is something a queue handoff?
-
-**Queue handoff** (`rigx queue handoff`):
-- Asks a known recipient to do new work
-- Transfers ownership of pending work
-- Names a deliverable + acceptance criteria
-
-**NOT a queue handoff**:
-- Wake-ping `1`
-- PSA / broadcast / status update
-- Ack / courtesy notification / diagnostic ping / reply to question
-- Raw idea or bug where you do not yet know the right owner
-
-If you do not know the correct owner, emit to stream instead of guessing.
-
-## Tier-based ack + notification rules
-
-- **human-gate tier** (gated items; human-watching): mandatory ack on handoff; mandatory notification on completion
-- **agent-coordination tier** (standard inter-agent work): recommended ack + notification
-- **internal-self tier** (your own to-dos): optional
-
-## Read discipline
-
-- Read your own queue at turn start before picking up new work
-- Orchestrators read pod-member queues on wake cadence (`1` ping)
-- Advisor-pod reads cross-rig queues for composed views + human-attention
-- Past-threshold blocked entries surface during sweeps; execute escalate op if you can't self-unblock
-
-Recommended turn-start queue commands on the live wrapper:
-
-```bash
-rigx queue whoami
-rigx queue list --mine
-```
-
-### Resume-from-idle state sweep
-
-Agents returning from idle-standby (supervisor-wake-only pings; no substantive dispatch during the window) MUST sweep adjacent state before pulling new work. Minimum sweep:
-
-- Supervisor-log tail (~200 lines) at `rigs/kernel/state/supervisor-log.md`
-- human-attention.md at `substrate/shared-docs/human-attention.md`
-- Any doctrine-decisions added since last-active (`rigs/kernel/state/doctrine-decisions/`)
-- Partner queue files at `rigs/kernel/state/<pod>/<peer-member>.queue.md` (peer load-tracking for pairs)
-- **Fleet-changes-feed** at `substrate/shared-docs/fleet-changes-feed.md` (pull-native rollout surface; catches any fleet-wide doctrine / skill / convention / operational changes that landed during idle; filter by scope = fleet-wide + your rig/pod)
-
-**Trigger:** first active turn after ≥3 consecutive wake-only cycles OR on peer HA-check request. Sweep before responding to HA-check so the response is grounded in current reality, not stale memory.
-
-**Rationale:** own-queue-at-turn-start catches own-queue drift; adjacent-state drift is a separate failure class that requires its own read discipline. Composable with own-queue sweep (both at same reading point); adds ~2-5 minutes of read time; cheap insurance against peer-driven HA-check round-trips.
-
-**Worked example (genesis):** advisor-co-observer@your-rig after ~2h idle-standing-by on 2026-04-13 — 5-of-7 HA-check items out-of-sync when peer queried. Rule addition would have caught the drift pre-query via adjacent sweep on wake-to-active transition.
-
-## Status-not-chat corollary
-
-Your chat pane is for operational work + ad-hoc human exchanges. Your STATUS lives in queue files + composed views. If you finish work + hit a gate-requiring next-action, do NOT narrate to chat + idle-wait. Queue-handoff to advisor-pod with `tier: human-gate`. The operator doesn't watch agent panes; they watch human-attention.md (composed from human-gate queue entries).
-
-## Composed views (4 layers)
-
-- **Pod-load view** — who's loaded / blocked (orch reads)
-- **Rig pending-work** — cross-pod roll-up
-- **Fleet cross-rig** — host-wide
-- **human-attention** — human-gate-tier items across all queues (advisor-pod composes)
-
-v0: manual regen by orchestrators + advisor-pod.
-v0.5: terminal-node watch scripts auto-regen.
-v1: generative UI consuming structured queue data.
-
-## Codex-sandbox proxy-write pattern (sanctioned workaround)
-
-Codex members whose sandbox blocks substrate writes can still participate via proxy-write:
-- Codex authors content locally (e.g., `/tmp/<rig>-attention-queue/<member>.queue.md`)
-- Claude counterpart physically writes to substrate with sha256-verified integrity check
-- Subsequent state transitions via `[queue-update: <id> <new-state> <reason>]` rig-send from Codex to Claude-writer
-- Authorship preserved; only write-access delegated. Distinct from peer-injection (which is forbidden).
-
-## Escalation mechanics
-
-When entry stays blocked past tier threshold AND agent can't self-unblock:
-
-1. Identify escalation target per authority chain:
-   - Pod member → pod orchestrator
-   - Pod orch → rig orch-lead
-   - Rig orch-lead → kernel orch-lead OR advisor-pod (if human-gate)
-   - Skip-levels allowed when agent KNOWS correct target
-2. Create new entry in escalation-target's queue with `escalated-from: <source-id>`; state=pending; priority elevated
-3. Send handoff-shape rig-send: `[queue-escalate: <new-id>] <title> — blocked <Nh> on <reason>`
-4. Update own entry: state=escalated; escalated-to=<target>/<new-id>; transitions-log appended
-
-Threshold guidance: 1h human-gate / 4h agent-coordination / 24h internal-self. Rigs may tighten.
-
-## Task-close RSI-check (flywheel trigger)
-
-Every `complete` op on substantive work reflects briefly: "what did we learn? is this worth filing as L2 capture to improvements-inbox?"
-
-Two outcomes; both leave evidence in the transition trail:
-
-- **Novel observation worth filing:** append L2 capture entry to `rigs/kernel/state/improvements-inbox.md` per the v1 queue template (`state: pending` + transition trail started). Transition line in your own queue: `<ts> — RSI-check: filed <capture-id>`.
-- **Nothing novel:** transition line in your own queue: `<ts> — RSI-check: none`.
-
-Applies to substantive work-streams. Does NOT apply to:
-- Wake-pings (`1`) — not a work-stream
-- Trivial status updates — nothing to reflect on
-- Pure acks / routing-map updates — no work done
-
-Rationale: task-close is the deterministic interval that makes recursive-self-improvement mechanical rather than ad-hoc. Pattern named in skill-maturity-convention.md §"Task-close RSI-check discipline".
-
-## Push vs pull — when to use rig-send vs queue-write
-
-Not every communication belongs in the receiver's chat pane. The discipline mirrors status-not-chat: most inter-agent signals can flow through queue files (pull) rather than rig-sends (push). Reduces noise; respects receiver's attention cycle.
-
-**Sender's test:** *Does my message need the receiver's attention within their next turn cycle?*
-- **Yes → push** via `rig send` (lands in chat; receiver processes on next turn)
-- **No → pull** via queue-write (write to own queue OR receiver's queue via handoff; receiver sweeps at cadence)
-
-### Push (rig-send to chat) when:
-
-- Receiver needs info NOW to unblock their work
-- Question requires specific answer to proceed
-- Handoff is past ack-threshold + tier=human-gate (mandatory-ack window)
-- Blocker surfacing (can't self-unblock; need help from target)
-- human-gate item needing surface to advisor-pod
-- Destructive or time-critical coordination
-
-### Pull (queue-write only) when:
-
-- Status update / adoption signal / cascade-complete ack
-- Non-urgent ack (within tier threshold)
-- Information that can batch in receiver's curator sweep
-- Broadcast-receipt confirmation (receiver's cadence catches it)
-- Observed patterns or captures with no time pressure
-- Resync material for HA peers (they sweep on resume-from-idle)
-
-### Why this matters
-
-Push-as-default floods the receiver's chat pane with status that could be pulled. Today's rollout volume proved this: during attention-queue + EMM cascades, most acks arrived as push (rig-sends) when they could have been pull (queue-writes). Receiver (advisor-pod) had to process each ping; most were status signals needing no action.
-
-Pull-over-push is the queue primitive's whole point. Status lives in queue files; readers sweep at cadence; only genuine unblockers + gate-surfaces push to chat.
-
-### Worked example
-
-orch-lead@your-rig ack'd attention-queue cascade:
-- **Push version (what happened):** `rig send advisor-peer-observer@your-rig "[queue-handoff-ack: ...] ... cascaded to 8 pod members ..."` → lands in my chat; I read immediately; process the status
-- **Pull version (what should happen):** write ack-receipt to `rigs/openrig-build/state/orch/lead.queue.md` as state-transition on their adoption entry; I sweep their queue on my curator cadence; pick up the ack without chat-ping
-
-Ack-receipts for status are pull-native. Handoff-complete notifications for human-gate items stay push (they close feedback loops on time-sensitive work).
-
-### Corollary — orchestrator-to-advisor cadence
-
-Orchestrators writing to their own queue files lets advisor-pod read without being interrupted. The curator-sweep pattern (advisor reads pod queues on their cadence) is the canonical pull mechanism. Push only when time-matters.
-
-## Anti-patterns (don't do these)
-
-- **Chat-as-status** — narrating status/gates to your chat pane + idle-waiting. Use queue + human-attention instead.
-- **Duplicate-storage** — writing the same fact in queue + session-log + chat + mission-control. Queue is authoritative for in-flight state.
-- **Peer-injection** — writing directly to another agent's queue without their authorship. Only handoff op moves work cross-queue.
-- **Silent drops** — don't leave items in pending forever without state transitions. defer or drop with rationale.
-- **Global queue** — don't try to make one queue for everyone. Per-agent primary; compose for views.
-
-## Maturity status
-
-**L4-insight** per skill-maturity-convention. Applied liberally across the host; evolving via observation. Feedback loop: RSI filings reshape this skill; demotion valid if convention reveals wrong shape; promotion to L5-canon requires architect+reviewer pair-review per HOST-TOPOLOGY §7 SOP.
-
-Rollout date: 2026-04-13 host-wide adoption. 48h observation cycle active; RSI with learnings due ~2026-04-15.
-
-## Related
-
-- Spec (full reference): the internal attention-queue spec
-- Skill-maturity convention: `substrate/shared-docs/skill-maturity-convention.md`
-- Config-wrapper-code loop doctrine: `config-wrapper-code-loop` skill
-- HOST-TOPOLOGY §4 context-sharing patterns — attention queue is a new pattern here
-- SUBSTRATE-CONVENTIONS §7 HA session logs — queue lives in same per-pod directory

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

@@ -1,48 +0,0 @@
----
-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 the operator-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, the operator-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 operator direction reverses.
-3. Bump `last_upstream_check` in `SKILL.md` frontmatter.

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

@@ -1,107 +0,0 @@
----
-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
-
-## Overview
-
-Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
-
-Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
-
-<HARD-GATE>
-Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
-</HARD-GATE>
-
-## Anti-Pattern: "This Is Too Simple To Need A Design"
-
-Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
-
-## Checklist
-
-You MUST create a task for each of these items and complete them in order:
-
-1. **Explore project context** — check files, docs, recent commits
-2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
-3. **Propose 2-3 approaches** — with trade-offs and your recommendation
-4. **Present design** — in sections scaled to their complexity, get user approval after each section
-5. **Write design doc** — save to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit
-6. **Transition to implementation** — invoke writing-plans skill to create implementation plan
-
-## Process Flow
-
-```dot
-digraph brainstorming {
-    "Explore project context" [shape=box];
-    "Ask clarifying questions" [shape=box];
-    "Propose 2-3 approaches" [shape=box];
-    "Present design sections" [shape=box];
-    "User approves design?" [shape=diamond];
-    "Write design doc" [shape=box];
-    "Invoke writing-plans skill" [shape=doublecircle];
-
-    "Explore project context" -> "Ask clarifying questions";
-    "Ask clarifying questions" -> "Propose 2-3 approaches";
-    "Propose 2-3 approaches" -> "Present design sections";
-    "Present design sections" -> "User approves design?";
-    "User approves design?" -> "Present design sections" [label="no, revise"];
-    "User approves design?" -> "Write design doc" [label="yes"];
-    "Write design doc" -> "Invoke writing-plans skill";
-}
-```
-
-**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
-
-## The Process
-
-**Understanding the idea:**
-- Check out the current project state first (files, docs, recent commits)
-- Ask questions one at a time to refine the idea
-- Prefer multiple choice questions when possible, but open-ended is fine too
-- Only one question per message - if a topic needs more exploration, break it into multiple questions
-- Focus on understanding: purpose, constraints, success criteria
-
-**Exploring approaches:**
-- Propose 2-3 different approaches with trade-offs
-- Present options conversationally with your recommendation and reasoning
-- Lead with your recommended option and explain why
-
-**Presenting the design:**
-- Once you believe you understand what you're building, present the design
-- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
-- Ask after each section whether it looks right so far
-- Cover: architecture, components, data flow, error handling, testing
-- Be ready to go back and clarify if something doesn't make sense
-
-## After the Design
-
-**Documentation:**
-- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
-- Use elements-of-style:writing-clearly-and-concisely skill if available
-- Commit the design document to git
-
-**Implementation:**
-- Invoke the writing-plans skill to create a detailed implementation plan
-- Do NOT invoke any other skill. writing-plans is the next step.
-
-## Key Principles
-
-- **One question at a time** - Don't overwhelm with multiple questions
-- **Multiple choice preferred** - Easier to answer than open-ended when possible
-- **YAGNI ruthlessly** - Remove unnecessary features from all designs
-- **Explore alternatives** - Always propose 2-3 approaches before settling
-- **Incremental validation** - Present design, get approval before moving on
-- **Be flexible** - Go back and clarify when something doesn't make sense

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

@@ -1,56 +0,0 @@
----
-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 operator 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,94 +0,0 @@
----
-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
-
-## Overview
-
-Load plan, review critically, execute tasks in batches, report for review between batches.
-
-**Core principle:** Batch execution with checkpoints for architect review.
-
-**Announce at start:** "I'm using the executing-plans skill to implement this plan."
-
-## The Process
-
-### Step 1: Load and Review Plan
-1. Read plan file
-2. Review critically - identify any questions or concerns about the plan
-3. If concerns: Raise them with your human partner before starting
-4. If no concerns: Create TodoWrite and proceed
-
-### Step 2: Execute Batch
-**Default: First 3 tasks**
-
-For each task:
-1. Mark as in_progress
-2. Follow each step exactly (plan has bite-sized steps)
-3. Run verifications as specified
-4. Mark as completed
-
-### Step 3: Report
-When batch complete:
-- Show what was implemented
-- Show verification output
-- Say: "Ready for feedback."
-
-### Step 4: Continue
-Based on feedback:
-- Apply changes if needed
-- Execute next batch
-- Repeat until complete
-
-### Step 5: Complete Development
-
-After all tasks complete and verified:
-- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
-- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
-- Follow that skill to verify tests, present options, execute choice
-
-## When to Stop and Ask for Help
-
-**STOP executing immediately when:**
-- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
-- Plan has critical gaps preventing starting
-- You don't understand an instruction
-- Verification fails repeatedly
-
-**Ask for clarification rather than guessing.**
-
-## When to Revisit Earlier Steps
-
-**Return to Review (Step 1) when:**
-- Partner updates the plan based on your feedback
-- Fundamental approach needs rethinking
-
-**Don't force through blockers** - stop and ask.
-
-## Remember
-- Review plan critically first
-- Follow plan steps exactly
-- Don't skip verifications
-- Reference skills when plan says to
-- Between batches: just report and wait
-- Stop when blocked, don't guess
-- Never start implementation on main/master branch without explicit user consent
-
-## Integration
-
-**Required workflow skills:**
-- **superpowers:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting
-- **superpowers:writing-plans** - Creates the plan this skill executes
-- **superpowers:finishing-a-development-branch** - Complete development after all tasks

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

@@ -1,48 +0,0 @@
----
-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 operator direction reverses.
-3. Bump `last_upstream_check` in `SKILL.md` frontmatter.