@openrig/cli 0.5.6 → 0.5.7

package/daemon/docs/reference/product-journey-sdlc.md

@@ -0,0 +1,305 @@
+# Product-journey SDLC components
+
+This is a reusable menu for building the smallest complete user outcome. A
+mission or slice selects only the components its work needs and records their
+order in mission/slice YAML. This is **not a mode, pipeline, topology, rig
+shape, or mandatory gate set**. If no composition is present, use the light
+Part A flow in `sdlc-conventions.md`.
+
+## The doghouse and the moon base
+
+The **doghouse** is the actual product outcome the user asked for. A
+**missing door** is an implementation that may be polished internally but
+cannot perform its basic user job. A **moon base** is elaborate machinery—
+often guards, abstractions, proof ceremony, security theatre, or process
+scaffolding—that consumes most of the effort without making the doghouse work.
+
+Use that disclosure ladder in this order:
+
+1. Name the doghouse in one sentence, without process vocabulary.
+2. Exercise its door through the public surface before admiring internals.
+3. Repair the smallest missing product seam.
+4. Consider deeper machinery only when evidence shows the layer below is
+   causing the visible failure.
+5. Remove or decline anything that does not protect or deliver a named user
+   outcome.
+
+The same discipline works for a new mission and for rescuing one that drifted.
+In a new mission, it prevents the moon base. In a rescue, it finds whether a
+usable doghouse remains and separates it from machinery that should not be
+carried forward.
+
+## Component contract
+
+Every component below states:
+
+- **Use when** — the evidence that admits it.
+- **Skip when** — the cheapest reason not to run it.
+- **Input** — what the responsible agent must actually read or observe.
+- **Action** — the bounded work performed.
+- **Output** — the artifact or observable result handed to the next component.
+- **Stop** — the boundary that prevents the component expanding itself.
+- **Next** — the normal successor; YAML may choose another explicit edge.
+
+Component IDs are stable addresses. Their prose may improve without forcing
+mission YAML to change.
+
+## Component catalog
+
+### context.fresh-start
+
+- **Use when:** prior context may carry stale architecture, verdicts, or
+  implementation momentum.
+- **Skip when:** the current agent can independently state the user outcome,
+  starting candidate, and boundaries from primary sources.
+- **Input:** world install, mission/slice YAML, and the addresses it names.
+- **Action:** start or clear a session, load only the selected context, and
+  derive current identity and source state.
+- **Output:** a one-paragraph readiness statement naming role, user outcome,
+  starting candidate, and boundaries.
+- **Stop:** do not reconstruct old queue lore merely because it exists.
+- **Next:** `intent.recover` or `journey.choose`.
+
+### intent.recover
+
+- **Use when:** work already exists but may have drifted from its original user
+  intent.
+- **Skip when:** this is greenfield work with one current, unambiguous intent.
+- **Input:** the earliest authoritative intent, later mission/slice specs,
+  candidate code, and observed user behavior.
+- **Action:** distinguish requirements from later planner elaboration; identify
+  the smallest still-required outcomes and explicit anti-goals.
+- **Output:** a concise salvage map: keep, inspect, and not-required—never a
+  destructive verdict by itself.
+- **Stop:** do not treat prior review intensity or sunk cost as product value.
+- **Next:** `journey.probe`.
+
+### journey.choose
+
+- **Use when:** a new mission has intent but no proven product path yet.
+- **Skip when:** `intent.recover` already names the next smallest outcome.
+- **Input:** authoritative intent and current public product surface.
+- **Action:** select one end-to-end user journey whose completion provides
+  standalone value.
+- **Output:** one observable outcome plus its smallest credible public probe.
+- **Stop:** one outcome only; adjacent capability is another composition.
+- **Next:** `journey.probe`.
+
+### journey.probe
+
+- **Use when:** always, before product code is added or rescued.
+- **Skip when:** never; scale the probe down instead.
+- **Input:** the public CLI, API, UI, or other surface a real user operates.
+- **Action:** run the smallest disposable end-to-end journey and inspect its
+  effects, not merely its exit status.
+- **Output:** PASS with no code needed, or one concrete user-visible gap with
+  preserved evidence.
+- **Stop:** a passing journey does not authorize speculative hardening.
+- **Next:** finish on PASS; otherwise `depth.look-below` or
+  `build.minimal-gap`.
+
+### depth.look-below
+
+- **Use when:** the public failure recurs, crosses a component boundary, is
+  contradicted by lower-level state, or a surface patch would duplicate logic
+  already owned below.
+- **Skip when:** the failure is local, understood, and repairable at the public
+  seam without duplication; also skip when the only argument is “more robust.”
+- **Input:** one observed public failure and the immediately responsible seam.
+- **Action:** descend **one layer only**; state the causal hypothesis, name the
+  lower-layer observation that would falsify it, and inspect or probe that
+  layer.
+- **Output:** one of three depth decisions:
+  - `LOCAL` — repair the public seam;
+  - `BELOW` — repair the named load-bearing seam and replay the public journey;
+  - `HOUSEKEEPING` — repair environment/data/topology hygiene before changing
+    product code.
+- **Stop:** one descent per admission. A second descent requires new evidence
+  and a newly stated hypothesis. “While here,” generalized prevention, and
+  unrelated cleanup are out of scope.
+- **Next:** `build.minimal-gap`, `research.before-build`, or housekeeping.
+
+This component is the balance point. Refusing ever to look below produces
+surface patches and recurring defects. Looking below without an evidence gate
+produces a moon base. The aim is the first load-bearing seam, not the deepest
+possible explanation.
+
+### research.before-build
+
+- **Use when:** the causal hypothesis depends on an unstable external fact or
+  a product contract that cannot be derived locally.
+- **Skip when:** source, runtime state, and the public probe already establish
+  the mechanism.
+- **Input:** one answerable uncertainty and its decision consequence.
+- **Action:** acquire only enough primary evidence to decide the implementation
+  shape.
+- **Output:** decision, citations, and remaining uncertainty.
+- **Stop:** research ends when the implementation decision is supported.
+- **Next:** `build.minimal-gap`.
+
+### build.minimal-gap
+
+- **Use when:** a failed journey and causal seam are established.
+- **Skip when:** `journey.probe` passed or the finding is housekeeping rather
+  than code.
+- **Input:** the user-visible gap, depth decision, existing seam, and explicit
+  boundaries.
+- **Action:** add the shortest readable change that completes the journey,
+  reusing the existing product seam.
+- **Output:** one clean candidate and focused evidence of the failure changing
+  for the stated reason.
+- **Stop:** no new framework, security layer, schema, abstraction, or adjacent
+  verb unless the outcome cannot work without it.
+- **Next:** `qa.public-journey`.
+
+### qa.public-journey
+
+- **Use when:** a candidate claims a complete user outcome.
+- **Skip when:** never before integration; it may be held by the builder on a
+  tiny change only when independence was not selected.
+- **Input:** exact candidate, original public probe, and boundaries.
+- **Action:** run the journey from the user surface in a disposable context;
+  inspect resulting state and partial-failure behavior.
+- **Output:** CLEAR or one concrete mismatch.
+- **Stop:** QA does not redesign the product or demand unselected ceremony.
+- **Next:** `review.scope-maintainability` or back to `build.minimal-gap`.
+
+### review.scope-maintainability
+
+- **Use when:** independent review is selected for the outcome.
+- **Skip when:** the composition deliberately keeps a low-risk change within
+  the light single-agent path.
+- **Input:** exact candidate, intent, public QA evidence, and base diff.
+- **Action:** judge correctness, readability, necessity, reuse of existing
+  seams, and whether the public journey—not an internal proxy—works.
+- **Output:** CLEAR or a bounded source/product finding.
+- **Stop:** a reviewer may not ratchet rigor merely because prior review found
+  something; review the product, not the ceremony.
+- **Next:** `integrate.one-outcome` or back to `build.minimal-gap`.
+
+### integrate.one-outcome
+
+- **Use when:** the selected evidence for one outcome is complete.
+- **Skip when:** the candidate is not clear or its base moved incompatibly.
+- **Input:** exact candidate identity and selected QA/review results.
+- **Action:** integrate the smallest coherent outcome and keep unrelated
+  candidates separate.
+- **Output:** clean canonical source containing one additional user outcome.
+- **Stop:** do not batch unrelated salvage because it shares a release label.
+- **Next:** `runtime.adopt` or the next `journey.choose`.
+
+### runtime.adopt
+
+- **Use when:** the outcome needs installed-runtime or migration proof.
+- **Skip when:** source-level proof is sufficient and no live behavior changed.
+- **Input:** clean canonical commit, rollback boundary, and runtime SOP.
+- **Action:** build/package/install the exact commit, switch atomically, and
+  verify health plus continuity.
+- **Output:** exact live version and preserved rollback point.
+- **Stop:** adoption is deployment, not permission to change topology or data.
+- **Next:** `qa.installed-smoke`.
+
+### qa.installed-smoke
+
+- **Use when:** `runtime.adopt` ran or packaging/path resolution is part of the
+  product claim.
+- **Skip when:** no installed artifact or runtime behavior is in scope.
+- **Input:** exact live version and disposable public journey.
+- **Action:** exercise the installed command path and verify effects and
+  cleanup.
+- **Output:** installed-runtime CLEAR or one concrete mismatch.
+- **Stop:** do not convert a smoke test into fleet-wide monitoring.
+- **Next:** finish the outcome or return to `build.minimal-gap`.
+
+## Composition rules
+
+1. `mission.yaml` may declare the catalog and mission defaults.
+2. `slice.yaml` selects or overrides the components for that slice.
+3. Edges are explicit data. Array order is presentation, not dependency.
+4. Select the fewest components that honestly fit the work.
+5. A component may be held by the same seat as its neighbor unless independence
+   is an intentional property of the composition.
+6. YAML describes the work; it is not an enforcement engine and creates no
+   automatic gates.
+
+Repository-address example:
+
+```yaml
+sdlc:
+  catalog:
+    root: repository
+    address: docs/reference/product-journey-sdlc.md#component-catalog
+  components:
+    - id: journey.choose
+      owner: planner
+    - id: journey.probe
+      owner: qa
+    - id: depth.look-below
+      owner: builder
+      admission: evidence-gated
+    - id: build.minimal-gap
+      owner: builder
+    - id: qa.public-journey
+      owner: qa
+  edges:
+    - from: journey.choose
+      to: journey.probe
+    - from: journey.probe
+      to: depth.look-below
+      when: public failure needs causal discrimination
+    - from: journey.probe
+      to: build.minimal-gap
+      when: local gap is already established
+    - from: depth.look-below
+      to: build.minimal-gap
+      when: decision is LOCAL or BELOW
+    - from: build.minimal-gap
+      to: qa.public-journey
+```
+
+Resolve repository addresses from `git rev-parse --show-toplevel`. Use the
+`loading-addressable-markdown` skill for `path#h2-slug` and
+`path#h2-slug/h3-slug` addresses outside the context library.
+
+## Example compositions
+
+### Greenfield product journey
+
+`context.fresh-start → journey.choose → journey.probe →
+build.minimal-gap → qa.public-journey → review.scope-maintainability →
+integrate.one-outcome`
+
+Add `depth.look-below` only when the probe meets its admission rule. A new
+mission does not need rescue archaeology.
+
+### Drifted-mission rescue
+
+`context.fresh-start → intent.recover → journey.probe →
+depth.look-below? → build.minimal-gap → qa.public-journey →
+review.scope-maintainability → integrate.one-outcome`
+
+The question is not “which old commits pass review?” It is “which required
+user outcome works, what prevents the next one, and how little code completes
+it?”
+
+### Recurring cross-layer defect
+
+`journey.probe → depth.look-below → research.before-build? →
+build.minimal-gap → qa.public-journey → qa.installed-smoke?`
+
+The recurrence admits one causal descent. It does not authorize a general
+platform rewrite.
+
+## Blank-agent start
+
+An agent with only the base world install should:
+
+1. Read `mission.yaml`, then the active `slice.yaml`.
+2. Resolve the catalog address and only the additional addresses those files
+   name.
+3. State: **my role; the user outcome; the starting candidate; the
+   boundaries**.
+4. Follow the selected component edges and their stop conditions.
+5. If no composition exists, use Part A in `mission-slice-sop`.
+6. If current reality contradicts the YAML, stop treating the YAML as fact,
+   record the discrepancy, and re-derive from the public journey and source.

package/daemon/docs/reference/sdlc-conventions.md

@@ -36,19 +36,26 @@ one does not deprecate the others. Nothing below deletes or overrides an existin
 |---|---|
 | **PRODUCT / MISSION PREPARATION** | **The product-management pass** — the layer above planning, run by the advisor/PM seat before planners touch a mission. The build is a lossy compression pipeline (PM intent → planner spec → builder code); nothing leaks downward by proximity, so this pass grounds in the raw sources, synthesizes ONE scope of record, presents owner decisions decision-ready, mints slices at plan time, deposits the full design contract INLINE in each design-bearing spec (owner words verbatim, settled decisions, evidence, shape of done, anti-goals), routes the complete reading list and internet-research assignments from the spec itself, frames each slice's planning-dial rung with its reason, and rereads every spec as the narrow downstream reader. The measuring stick: SPEC.md alone, plus what it explicitly routes to, reproduces the intent in a reader with none of the author's context. Full reference: `product-management-pass.md`. |
 | **PLAN** | **The planning dial** — planning rigor is a spectrum chosen per piece: P0 mini-requirements and pointers (simple, reversible work) · P1 an authored spec with a proof contract (the default) · P2 plus a research round before the spec freezes, run BEFORE build dispatch · P3 plus an adversarial pass by a non-author, judged against product goals, landing amendments with proof-contract teeth · P4 plus a blind from-scratch design diffed against priors before proceeding. Dial up by what the piece is, exactly as build care is priced below. Full reference: `planning-dial.md`. |
-| **BUILD** | **Part A, the simple flow** (below — the default) · **the wave model** — slices build in parallel in disjoint file territories, an integrator merges serially, and independent review fires once per wave (two reviewers with different vantages, never the writers; fix rounds re-earn verdicts at one final revision; per-slice discipline stays failing-test-first and verify-by-effect). The wave IS the care dial: what shares a wave decides how much review each piece gets · **Part B, the rigorous overlay** (below — only when assigned). These combine: a wave can carry one Part-B piece. Full wave reference: `wave-sdlc.md`. |
+| **BUILD** | **Part A, the simple flow** (below — the default) · **product-journey components** — a mission-selectable menu for greenfield work, drift recovery, public journey probes, one evidence-gated look at the layer below, minimal repair, independent QA/review, integration, and installed smoke; compose only what the work needs in mission/slice YAML, never as a new mode or mandatory pipeline. Full reference: `product-journey-sdlc.md` · **the wave model** — slices build in parallel in disjoint file territories, an integrator merges serially, and independent review fires once per wave (two reviewers with different vantages, never the writers; fix rounds re-earn verdicts at one final revision; per-slice discipline stays failing-test-first and verify-by-effect). The wave IS the care dial: what shares a wave decides how much review each piece gets · **Part B, the rigorous overlay** (below — only when assigned). These combine: a wave can carry one Part-B piece. Full wave reference: `wave-sdlc.md`. |
 | **DISPATCH DATA** | **The execution-data conventions (S27)** — three tiny data disciplines that make execution state derivable instead of hand-tabulated, consumed by `rig view show execution`. **EC-1, edges in frontmatter:** every open slice carries its hard edges in `depends_on:` (an inline JSON array; an explicit `[]` is a statement, absence is INDETERMINATE); soft/serialization edges are one machine-readable Territory line, exactly `SOFT-AFTER: [ids] — reason`. **EC-2, wave-as-data:** wave composition + review model live on a durable queue row tagged `wave-map` + `format:wave-map-v1` whose body carries one fenced ```json block (`{format:"wave-map-v1", mission, waves:[{id, slices, serialized_order?, review_model?}]}`) — composition only, never status labels (status derives at read time); the planning dial recorded at lock surfaces as the frontmatter field `approved-spec-dial:` beside the approve stamp. **EC-3, dispatch names the worktree:** build batons carry the exact body line `worktree_path=<path>` from dispatch onward — it is Q1's join key; batons without it join by naming only and the view marks them `fragile_join`. Existing batons are never rewritten. |
 | **RELEASE** | The release ceremony conventions (publication identity, honest release notes) and the CAPABILITY-DELTA LIFECYCLE LAW: each release's delta is authored at the fence, bound to the exact published cut; canon absorbs its named items; the canon header then names the delta, which expires it — verify the expiry fired, and never cite an expired delta. Full statement: `release-boundary.md` §6. |
 | **BOUNDARY** | **The release boundary** — housekeeping run once per fence so the next release starts clean: seats reset or re-primed per their continuity needs, memory distilled (keep what changed a decision recently), every queue swept by destination and dispositioned, substrate torn down, boards frozen as records, a clean-box baseline captured. A checklist of judgment guides, not gates. Full reference: `release-boundary.md`. |
 
 > Full reference documents for each component (graduated 2026-08-28): the
 > product-management pass — `product-management-pass.md` · the
-> planning dial — `planning-dial.md` · the wave model — `wave-sdlc.md` · the release
+> planning dial — `planning-dial.md` · the product-journey component catalog —
+> `product-journey-sdlc.md` · the wave model — `wave-sdlc.md` · the release
 > boundary (including the capability-delta lifecycle law) — `release-boundary.md` ·
 > the mission install — `mission-install.md` (lands with its own slice). The
 > summaries above remain the one-glance description; this document remains the SSOT
 > pointer for the whole menu.
 
+Mission and slice YAML may select component IDs from
+`product-journey-sdlc.md` and record explicit edges between them. That YAML is
+an address map and execution dashboard prototype, not an enforcement engine.
+If it is absent, Part A remains the complete default; agents do not invent a
+composition merely to make one exist.
+
 # PART A — THE SIMPLE SDLC (applies always)
 
 ## A1. The flow in one pass

package/daemon/specs/agents/apps/vault-specialist/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, systematic-debugging, verification-before-completion, vault-user]
+      skills: [systematic-debugging, verification-before-completion, vault-user]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/apps/vault-specialist/guidance/role.md

@@ -26,7 +26,6 @@ You are the Vault specialist agent for this managed app. You are the domain expe
 
 You have the following skills loaded:
 
-- `using-superpowers` — general agent capabilities
 - `openrig-user` — OpenRig CLI and topology operations
 - `systematic-debugging` — structured debugging approach
 - `verification-before-completion` — evidence before claims

package/daemon/specs/agents/conveyor/builder/agent.yaml

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

package/daemon/specs/agents/conveyor/builder/guidance/role.md

@@ -11,7 +11,6 @@ reviewer can inspect.
 - `development-team`
 - `test-driven-development`
 - `systematic-debugging`
-- `executing-plans`
 - `verification-before-completion`
 
 ## Responsibilities

package/daemon/specs/agents/conveyor/lead/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [orchestration-team, backlog-capture, writing-plans, executing-plans, verification-before-completion, brainstorming]
+      skills: [orchestration-team, backlog-capture, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/conveyor/lead/guidance/role.md

@@ -11,10 +11,7 @@ ready.
 - `mission-slice-sop`
 - `orchestration-team`
 - `backlog-capture`
-- `writing-plans`
-- `executing-plans`
 - `verification-before-completion`
-- `brainstorming`
 
 ## Responsibilities
 

package/daemon/specs/agents/conveyor/planner/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [requirements-writer, context-builder, writing-plans, verification-before-completion]
+      skills: [requirements-writer, context-builder, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/conveyor/planner/guidance/role.md

@@ -10,7 +10,6 @@ execute without guessing.
 - `mission-slice-sop`
 - `requirements-writer`
 - `context-builder`
-- `writing-plans`
 - `verification-before-completion`
 
 ## Responsibilities

package/daemon/specs/agents/design/product-designer/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, development-team, frontend-design, verification-before-completion, writing-plans, brainstorming]
+      skills: [development-team, frontend-design, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,8 @@ startup:
     - type: send_text
       value: >-
         A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: using-superpowers, frontend-design,
-        verification-before-completion, writing-plans, brainstorming. Load them first, then begin
-        the work.
+        using your runtime's supported skill mechanism: frontend-design,
+        verification-before-completion. Load them first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/design/product-designer/guidance/role.md

@@ -5,13 +5,10 @@ You are the design side of the product team. Your job is to turn rough product i
 ## Startup checklist
 
 Load these packaged skills now before giving product direction:
-- `using-superpowers`
 - `openrig-user`
 - `mission-slice-sop`
 - `development-team`
 - `frontend-design`
-- `brainstorming`
-- `writing-plans`
 - `verification-before-completion`
 
 Then run `rig whoami --json` and look for the first ambiguity the development pod should not have to guess through.

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

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, development-team, test-driven-development, systematic-debugging, verification-before-completion, writing-plans, executing-plans]
+      skills: [development-team, test-driven-development, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,8 @@ startup:
     - type: send_text
       value: >-
         A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: using-superpowers, test-driven-development,
-        systematic-debugging, verification-before-completion, writing-plans, executing-plans. Load
-        them first, then begin the work.
+        using your runtime's supported skill mechanism: test-driven-development,
+        systematic-debugging, verification-before-completion. Load them first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/development/implementer/guidance/role.md

@@ -5,14 +5,11 @@ You are the implementation side of a dev pair. Your job is to write code, not to
 ## Startup checklist
 
 Load these packaged skills now before editing:
-- `using-superpowers`
 - `openrig-user`
 - `mission-slice-sop`
 - `development-team`
 - `test-driven-development`
 - `systematic-debugging`
-- `writing-plans`
-- `executing-plans`
 - `verification-before-completion`
 
 Then run `rig whoami --json` and wait for the orchestrator + QA loop before making changes.

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

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, test-driven-development, development-team, systematic-debugging, verification-before-completion, agent-browser, dogfood, writing-plans, executing-plans]
+      skills: [test-driven-development, development-team, systematic-debugging, verification-before-completion, agent-browser, dogfood]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,9 @@ startup:
     - type: send_text
       value: >-
         A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: using-superpowers, test-driven-development,
-        systematic-debugging, verification-before-completion, agent-browser, dogfood, writing-plans,
-        executing-plans. Load them first, then begin the work.
+        using your runtime's supported skill mechanism: test-driven-development,
+        systematic-debugging, verification-before-completion, agent-browser, dogfood. Load them
+        first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/development/qa/guidance/role.md

@@ -5,17 +5,14 @@ You are the quality assurance side of a dev pair. You gate every edit the implem
 ## Startup checklist
 
 Load these packaged skills now before reviewing work or dogfooding:
-- `using-superpowers`
 - `test-driven-development`
 - `openrig-user`
 - `mission-slice-sop`
 - `development-team`
 - `systematic-debugging`
+- `verification-before-completion`
 - `agent-browser`
 - `dogfood`
-- `writing-plans`
-- `executing-plans`
-- `verification-before-completion`
 
 Then run `rig whoami --json` and be ready to gate the implementer's first proposal before any edit lands.
 

package/daemon/specs/agents/factory-rsi/dogfood/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, dogfood, systematic-debugging, verification-before-completion]
+      skills: [dogfood, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/factory-rsi/release-manager/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, verification-before-completion]
+      skills: [verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/orchestration/orchestrator/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, orchestration-team, systematic-debugging, verification-before-completion, writing-plans, executing-plans, brainstorming]
+      skills: [orchestration-team, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,8 @@ startup:
     - type: send_text
       value: >-
         A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: using-superpowers, systematic-debugging,
-        verification-before-completion, writing-plans, executing-plans, brainstorming. Load them
-        first, then begin the work.
+        using your runtime's supported skill mechanism: systematic-debugging,
+        verification-before-completion. Load them first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/orchestration/orchestrator/guidance/role.md

@@ -5,14 +5,10 @@ You are the orchestrator. You coordinate the work of other agents in this rig, m
 ## Startup checklist
 
 Load these packaged skills now before doing substantive work:
-- `using-superpowers`
 - `openrig-user`
 - `mission-slice-sop`
 - `orchestration-team`
 - `systematic-debugging`
-- `brainstorming`
-- `writing-plans`
-- `executing-plans`
 - `verification-before-completion`
 
 Then run:

package/daemon/specs/agents/review/independent-reviewer/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, review-team, systematic-debugging, verification-before-completion, writing-plans, brainstorming]
+      skills: [review-team, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,8 @@ startup:
     - type: send_text
       value: >-
         A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: using-superpowers, systematic-debugging,
-        verification-before-completion, writing-plans, brainstorming. Load them first, then begin
-        the work.
+        using your runtime's supported skill mechanism: systematic-debugging,
+        verification-before-completion. Load them first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/review/independent-reviewer/guidance/role.md

@@ -5,13 +5,10 @@ You are an independent code reviewer. You analyze code on your own merits withou
 ## Startup checklist
 
 Load these packaged skills now before reviewing:
-- `using-superpowers`
 - `openrig-user`
 - `mission-slice-sop`
 - `review-team`
 - `systematic-debugging`
-- `brainstorming`
-- `writing-plans`
 - `verification-before-completion`
 
 Then run `rig whoami --json`, inspect the current rig state, and stay ready for the first meaningful milestone or working-tree review.