@openrig/cli 0.5.5 → 0.5.7

package/daemon/context-packs/skills/core/messaging-the-human/manifest.yaml

@@ -0,0 +1,10 @@
+# GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
+# Package-time projection of a canonical skill; regenerated every build.
+name: "messaging-the-human"
+version: "0.5.7"
+taxonomy: "skills"
+purpose: "Use when a human decision, access grant, external action, or escalation must survive the operator's absence, or when an orchestrator or PM has a judgment-worthy update for the operator."
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "Use when a human decision, access grant, external action, or escalation must survive the operator's absence, or when an orchestrator or PM has a judgment-worthy update for the operator."

package/daemon/context-packs/skills/core/openrig-architect/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-architect"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself (use openrig-builder); NOT for ordinary CLI operation of an existing rig (use openrig-user). Covers the full authoring lifecycle from user intent to validated, launchable rig."
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/openrig-cmux/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-cmux"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when opening OpenRig fleet terminals into cmux — turning a rig, pod, mission, slice, or saved view into live agent tiles via `rig terminal --provider cmux`, or driving cmux on an agent's request. Same OpenRig view semantics as openrig-herdr (the verbs, honest-partial/degrade, read-only cross-rig, scroll/copy, same-size-only duplicates); cmux is the **best-effort** provider (herdr is the default and the proof-gated one). Prefer openrig-herdr unless cmux is specifically wanted."
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/openrig-herdr/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-herdr"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when opening OpenRig fleet terminals as a herdr wall — turning a rig, pod, mission, slice, or saved view into live interactive agent tiles via `rig terminal`, watching another rig read-only, or driving herdr on an agent's request (\"open all my rigs + a mission as views\"). Covers the `rig terminal open|views|status` verbs, the honest-partial/degrade reading of the result, the read-only-by-construction rail for cross-rig views, scroll/copy out of the box, and the same-size-only duplicate-pane "
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/openrig-skills/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: openrig-skills
+description: "Use when you're operating OpenRig and need the right skill or context for fleet recovery, seat handover, new-seat orientation, a watchdog wake, cross-host reach to an agent on another machine, rig packaging, an OpenRig upgrade, systematic debugging, queue triage, or implementation planning; also use when you don't know what applies or nothing is projected on cold boot."
+allowed-tools: Bash(rig:*)
+metadata:
+  openrig:
+    stage: shipped
+---
+
+# OpenRig skills — the index (start here)
+
+You're running inside OpenRig. OpenRig ships a set of **skills** — small documents that tell you *when* to do something and *how*. This file is the map: what ships, when to reach for each, and how to load it. If you don't know which skill applies, or nothing is projected into your context, **start here.**
+
+## How OpenRig context works (30 seconds)
+
+Skills are **progressive disclosure**: a skill's *name + description* sit in your context ambiently (the "hot tier"); its *body* loads only when you open it. So you don't pre-read everything — you pattern-match a skill's "when" to your moment, then open just that one. This file is the index over the whole shipped set. (For the full model of building/operating agent software, open `software-for-agents`.)
+
+Every row below names **how to reach the skill** — already-hot, or an exact load path. No row is a dead end.
+
+## Loading an entry on demand — `rig context get`
+
+Don't guess a file path or a name. Go **ask → ref → load** in three steps:
+
+1. **Discover** — run `rig context list` for every shipped entry's **ref** and name. The *when* for
+   each is the index below (or `rig context list --json`, which carries each entry's purpose) — match
+   your moment there.
+2. **Select** — match your moment to a row's *when* and take its **ref**. Refs are canonical full paths
+   that mirror the library layout — `skills/<namespace>/<name>` (e.g. `skills/core/rig-lifecycle`,
+   `skills/process/systematic-debugging`). A unique bare name (e.g. `watchdog`) also resolves; any
+   slash-bearing ref is an exact lookup and fails loud if it does not exist.
+3. **Load** — `rig context get skills/<namespace>/<name>`:
+
+```
+rig context get skills/core/rig-lifecycle
+```
+
+The router itself is available through both forms it teaches:
+`rig context get openrig-skills` and `rig context get skills/core/openrig-skills`.
+
+The content is served **from the installed CLI**, so what you load always matches your running version —
+no path-guessing, no frozen-fork drift. (The daemon assembles the same bundle `rig context preview`
+shows an operator — `get` is the agent-facing pull.)
+
+## The index
+
+> Membership rule (`layout.skills[*].edges.length > 0`): every public skill with at least one product edge in the generated edge layout appears exactly once in this index; no other skill appears.
+
+### Always loaded — the universal spine (open its body when its moment hits)
+These are auto-delivered to every rig; their name+description are already in your context. Open the body when the "when" matches.
+
+- **forming-an-openrig-mental-model** — first boot, or you're unsure how the pieces fit. The runtime mental model.
+- **openrig-operating-model** — you do not know where context or work belongs, or you are about to duplicate knowledge. The two-tree placement and trace-to-root model.
+- **openrig-user** — you need a `rig` CLI command (send / queue / ps / whoami / scope / broadcast). The daily CLI surface.
+- **applying-a-permission-policy** — a rig or seat has a permission policy attached, or you're setting one up: translate it into the live harness configuration.
+- **claude-compaction-restore** — you just compacted (Claude). Restore from durable evidence before resuming real work.
+- **delegating-work** — deciding who should do a task: you, a spawned subagent, or a durable peer seat that already holds the context.
+- **loading-addressable-markdown** — a task names Markdown as `path#h2-slug` or `path#h2-slug/h3-slug` outside the context-pack library.
+- **session-compaction-and-restore** — preparing for, or recovering from, compaction (any runtime). The write- and read-side protocol.
+- **queue-handoff** — you're passing durable work to another seat or ending your turn. The queue is the work ledger, not chat.
+- **refocusing** — a long-running seat may have lost the product outcome, crossed a major boundary, or compacted and needs a fresh path-based trace.
+- **seat-continuity-and-handover** — handing your seat's work across a restart or to another owner.
+- **orienting-to-an-inherited-seat** — you just inherited an existing seat through a planned handover and need to verify its identity, state, and testimony.
+- **retiring-and-inheriting-a-seat** — you're planning a seat transition and need to retire the current occupant into a fresh successor without losing continuity.
+- **mission-slice-sop** — you're working a mission/slice (the SDLC: intent → mini-requirements + proof contract → build → QA → proof). The operating manual.
+- **messaging-the-human** — composing a message to the human. Plain language, no insider jargon.
+- **software-for-agents** — you want the full first-load model of how agent software is built and operated here.
+- **openrig-skills** — this index (you're reading it). Always loaded; the entry point to everything below.
+
+### Load when your role or task calls for it (repo-shipped, profile-selected)
+These ship in the OpenRig repo and reach a seat when its profile selects them. To use one, select it in your profile's `uses.skills`, or open it directly at `packages/daemon/specs/agents/shared/skills/core/<skill>/SKILL.md`.
+
+- **openrig-architect** — authoring a rig or topology (NOT for changing OpenRig itself — that's `openrig-builder`).
+- **openrig-cmux** — driving the `cmux` terminal provider.
+- **openrig-herdr** — opening/managing seat terminals via the default proof-gated provider.
+- **agent-startup-and-context-ingestion** — a seat is booting and ingesting its startup context.
+- **topology-mutation-and-seat-management** — adding, removing, renaming seats or otherwise mutating rig topology.
+- **rig-lifecycle** — rig up / down / pause / resume lifecycle operations.
+- **rig-bundles-and-shareable-artifacts** — packaging or installing a rig bundle / shareable artifact.
+- **cross-host-rig-commands** — reaching seats or queues on another host (`--host`).
+- **openrig-upgrade** — upgrading OpenRig or the daemon.
+- **agent-starters** — composing an agent's starter context / priming packs.
+- **specification-system** — authoring or reading AgentSpecs and rig specs.
+- **human-in-the-loop** — deciding when to involve the human vs. proceed on your own authority.
+- **watchdog** — monitoring or recovering a seat (health, restore, stuck state).
+- **session-source-fork** — forking a session's source/context.
+- **context-engineering** — designing context systems. Provisional and non-normative: current OpenRig skills, explicit rulings, and measured practice outrank it on any conflict.
+
+Pod handbooks (load when you're in that pod):
+- **orchestration-team** — you're orchestrating a rig: dispatching, monitoring, keeping the loop moving.
+- **development-team** — you're on the dev pod: building and shipping product changes.
+- **review-team** — you're reviewing: fresh scrutiny, anti-slop, empirical verification.
+- **oversight-team** — you're in an oversight pod: monitor boundaries and route findings without taking over the work.
+
+Product-management craft (load when shaping/reviewing work):
+- **requirements-writer** — turning intent into clear requirements.
+- **plan-review** — reviewing a plan before it's built.
+- **exec-summary** — writing a decision-ready summary for a human.
+- **office-hours** — running a structured advisory / decision session.
+- **context-builder** — assembling the context a task or seat needs.
+- **backlog-capture** — capturing and shaping backlog items.
+- **ui-mockup** — producing a UI mockup for a slice.
+
+### Vendored craft — load when you're coding (ships with upstream provenance)
+General engineering skills OpenRig ships as vendored copies. Open when the task matches; they carry "modified by OpenRig" provenance.
+
+- **test-driven-development** — implementing a feature or bugfix: write the failing test first.
+- **verification-before-completion** — about to claim done / passing / fixed: run the check and read the output first.
+- **systematic-debugging** — debugging: find the root cause before the fix.
+- **agent-browser** — driving a browser (screenshot / screencast) from an agent.
+- **frontend-design** — designing frontend / UI.
+- **dogfood** — web-QA / dogfooding a shipped UI.
+
+## Need more than what ships here?
+
+This index covers the **shipped** surface. A dev host carries far more (factory, architecture, PM-craft, studio skills) reached through the host's own routers/codemaps — if you're on a builder host and need something not listed above, that deeper routing is the next hop, not a wall. (Host-scale routing is the subject of the context-routing architecture doc; at product scale, this one file is the whole map.)

package/daemon/context-packs/skills/core/openrig-skills/manifest.yaml

@@ -0,0 +1,10 @@
+# GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
+# Package-time projection of a canonical skill; regenerated every build.
+name: "openrig-skills"
+version: "0.5.7"
+taxonomy: "skills"
+purpose: "Use when you're operating OpenRig and need the right skill or context for fleet recovery, seat handover, new-seat orientation, a watchdog wake, cross-host reach to an agent on another machine, rig packaging, an OpenRig upgrade, systematic debugging, queue triage, or implementation planning; also use when you don't know what applies or nothing is projected on cold boot."
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "Use when you're operating OpenRig and need the right skill or context for fleet recovery, seat handover, new-seat orientation, a watchdog wake, cross-host reach to an agent on another machine, rig packaging, an OpenRig upgrade, systematic debugging, queue triage, or implementation planning; also use when you don't know what applies or nothing is projected on cold boot."

package/daemon/context-packs/skills/core/openrig-upgrade/SKILL.md

@@ -133,7 +133,7 @@ Observed result:
 - The old daemon was stopped without running `rig down`.
 - The new source-pinned daemon started against the same production DB.
 - `rig ps --nodes --json`, `rig capture`, and `rig restore-check` could inspect the
-  still-running Velocity seats after restart.
+  still-running continuity seats after restart.
 
 The simpler model is now preferred for tmux-backed continuity rigs: snapshot and
 back up state, stop only the daemon, start the new daemon, then verify that live
@@ -235,9 +235,7 @@ are tmux-backed and the operator wants non-disruptive daemon upgrade.
    blockers.
 
 10. **Align the default CLI with the new daemon.**
-    If `rig` is a wrapper, make sure it delegates to the new CLI. On the
-    2026-04-27 host this meant repointing the rigx real CLI via
-    `~/.openrig/bin/rig-real-17812d5`.
+    If `rig` is a wrapper, make sure it delegates to the new CLI.
 
 11. **Write evidence and hand back.**
     The sidecar writes a cutover evidence packet with daemon provenance,
@@ -245,73 +243,27 @@ are tmux-backed and the operator wants non-disruptive daemon upgrade.
     results, caveats, and rollback state. Then it notifies the original in-rig
     lifecycle/runtime-upgrade owner. Do not rely on chat as the only proof.
 
-## 2026-04-27 Proof Point
+## Proof Point: Daemon-Only Hot Cutover
 
-Continuity target:
+A clean source runtime on an LTS Node version replaced the old daemon while one
+tmux-backed continuity rig stayed live. The operator took a post-snapshot online
+database backup, verified its integrity, stopped only the daemon, started the
+new runtime against the same database, and confirmed that every protected seat
+remained running and ready with no red restore blockers.
 
-- `example-seat`
-
-Pinned daemon:
-
-- commit `17812d5d3bfe53dfdc5e202b1da3e8c91e2f4e54`
-- subject `feat(agents): make runtime config spec-driven`
-- committed `2026-04-26T18:30:08-07:00`
-- runtime worktree `~/code/projects/openrig-runtime-17812d5`
-
-Evidence:
-
-- Velocity snapshot `01KQ84D3AF9YW6FQCM9SVSM5EG`
-- post-snapshot DB backup
-  `db-backup/openrig-post-velocity-snapshot-20260427T185003Z.sqlite`
-- backup integrity `ok`
-- old daemon PID `62828`, Node 25 global npm install
-- new daemon PID `39708`, Node 22 source runtime
-- post-cutover `example-seat`: 4/4 seats `running` / `ready`
-- `rig restore-check --rig example-seat`: `RESTORABLE WITH CAVEATS`,
-  `20 green | 9 yellow | 0 red`, `RECOVERY: NOT NEEDED`
-
-Important caveat: this proves hot daemon cutover for tmux-backed Claude seats on
-this host and commit range. It does not prove that arbitrary migrations,
+Important caveat: this proves hot daemon cutover for the tested tmux-backed
+Claude runtime shape. It does not prove that arbitrary migrations,
 non-tmux runtimes, service-backed rigs, or dead sessions can be recovered without
 separate testing.
 
-## 2026-05-02 Proof Point
-
-Continuity targets:
-
-- `kernel`
-- `openrig-discovery`
-- `openrig-dogfood`
-- `openrig-lifecycle`
-- `openrig-maintenance`
-- `openrig-product-lab`
-- `example-rig`
-- `example-seat`
-
-Pinned daemon:
+## Proof Point: Out-of-Band Sidecar Cutover
 
-- commit `6af2754824a07291562622ac019b68615fc41abe`
-- runtime worktree `~/code/projects/openrig-runtime-6af2754`
-- wrapper `~/.openrig/bin/rig-real-6af2754`
-
-Pattern proven:
-
-- lifecycle/runtime-upgrade prepared the decision and preflight artifacts;
-- a host-local tmux sidecar (`host-upgrade-operator-6af2754`) was spawned
-  outside the managed topology with the current operator context;
-- the sidecar stopped only the daemon, using verified PID fallback after
-  `rig daemon stop` refused due to missing daemon state;
-- the sidecar started the target daemon on port `7433`, repointed the
-  config-layer wrapper default, verified protected topology, ran targeted
-  Agent Starter smoke/tests, wrote evidence, and unblocked Dogfood;
-- Velocity delivery continued working throughout the cutover.
-
-Evidence:
-
-- preflight:
-  (internal upgrade-preflight evidence, 2026-05-01)
-- live cutover:
-  (internal live-cutover evidence, 2026-05-02)
+A lifecycle owner prepared the decision and preflight artifacts, then spawned a
+host-local tmux sidecar outside the managed topology. The sidecar stopped only
+the daemon, used a verified graceful PID fallback when daemon state was stale,
+started the pinned runtime, aligned the default wrapper, verified the protected
+topology, ran targeted smoke checks, retained cutover evidence, and handed the
+result back while delivery continued.
 
 Important caveat: live `rig up --plan --json` accepted valid `starter_ref`
 specs and rejected forbidden compositions, but plan-mode output did not emit the
@@ -320,10 +272,6 @@ This is a product/dogfood caveat, not an upgrade failure.
 
 ## Brittle Edges Observed On 2026-04-27
 
-Detailed field note:
-
-(internal upgrade-brittleness field note, 2026-04-27)
-
 Operator lessons from the daemon upgrade:
 
 - `rig down` kills OpenRig-launched tmux sessions. Do not use it as a snapshot
@@ -340,15 +288,11 @@ Operator lessons from the daemon upgrade:
   verify the port is gone before starting the target daemon.
 - CLI and daemon provenance can drift. Repointing or verifying the default
   `rig` wrapper is part of the upgrade, not an afterthought.
-- Raw `rig ps` is too noisy on this host. Use filtered JSON until the product
+- Raw `rig ps` output can be noisy. Use filtered JSON until the product
   has compact first-class inventory views.
 - Snapshot and backup verification is too manual. The SOP currently depends on
   checking snapshot rows, resume tokens, SQLite backups, and integrity by hand.
 
-Separate follow-on note, not part of the daemon-upgrade SOP:
-
-(internal add-node-brittleness field note, 2026-04-27)
-
 ## Disruptive Restore Path
 
 Use disruptive restore when the goal is to test recovery from killed sessions, or
@@ -433,7 +377,7 @@ Needed product surfaces:
   `rig version --json` should report CLI path, daemon path, commit/package
   version, Node version, DB path, and started-at.
 - Wrapper alignment:
-  rigx/default `rig` should clearly show which real CLI it delegates to.
+  the default `rig` wrapper should clearly show which real CLI it delegates to.
 - Compact inventory:
   first-class `rig ps --rig <name> --nodes --compact` or equivalent, so
   operators do not need ad hoc `jq` for routine safety checks.

package/daemon/context-packs/skills/core/openrig-upgrade/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-upgrade"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when upgrading the OpenRig CLI/daemon on a host with running rigs, especially when preserving tmux-backed agent sessions through a daemon restart or documenting hot-upgrade SOP evidence."
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/rig-bundles-and-shareable-artifacts/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "rig-bundles-and-shareable-artifacts"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when authoring or installing a rig bundle (packaged, shareable artifact that instantiates an opinionated OpenRig topology + workflow), reasoning about the bundle vs extension boundary, or auditing a bundle for portability. Covers the 4 failure modes that prevent bundles from working anywhere but the operator's machine, and the inspect-before-install discipline."
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/rig-lifecycle/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "rig-lifecycle"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when reasoning about the rig lifecycle operations family (create / start / stop / resume / restore / snapshot / release / unclaim / destroy), reading or trusting `rig ps` / lifecycle projections after recovery, or designing proof for a lifecycle scenario. Covers the 4 failure modes (auto-restore creates partial rig; projections report healthier than reality; provider auth treated as impl work; resume succeeds for one runtime fails another) plus the restore-honesty rule (failed resume is FAIL"
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/session-source-fork/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "session-source-fork"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when authoring a rig spec member or `rig expand` payload that needs to start a new managed seat from a prior runtime conversation source — `session_source: { mode: fork, ref: { kind, value } }`. v1 supports `mode: fork` with `ref.kind: native_id` for Claude and Codex. The new seat persists a NEW post-fork token; the parent token is NEVER written onto the new seat. NOT for restoring an existing seat or for artifact-backed mental-model rebuild."
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/specification-system/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "specification-system"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when authoring rig specs, agent specs, workflow specs, startup/context fragments, operating-mode declarations, or designing the user spec library. Covers the 4 failure modes (spec instantiates topology but not workflow/mode; spec depends on local paths and fails on another host; agents modify specs as one-off files instead of preserving reusable intent; validation proves YAML shape but not whether topology can run) and the validation-vs-runtime-realization distinction."
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/topology-mutation-and-seat-management/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "topology-mutation-and-seat-management"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when changing a rig while it is alive — `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures."
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/watchdog/SKILL.md

@@ -85,20 +85,14 @@ explicit:
 - **Consumer-pool wake**: if a ready artifact exists, wake the consumer loop head.
 - **Producer-edge repair**: if upstream completion exists but the downstream artifact is missing, wake the producer loop head.
 
-**Scan cadence and wake cadence are separate.** Worked example (from the
-RSI v2 mission, now archived — the numbers are era-specific, the
-scan-vs-wake separation is the durable rule): scan every 30 seconds, wake
-at most every 600 seconds while work remains actionable.
+**Scan cadence and wake cadence are separate.** Worked example (the numbers
+are illustrative; the scan-vs-wake separation is the durable rule): scan every
+30 seconds, wake at most every 600 seconds while work remains actionable.
 
 This is not a generic workflow engine. It's a guardrail against cold
 pools and missing edge artifacts.
 
-## Two surfaces: rigx watchdog (config-layer) and rig watchdog (daemon-shipped)
-
-| Surface | Status | Policies |
-|---|---|---|
-| `rigx watchdog` (config-layer dogfood) | Tmux-backed loops; coexists with daemon | Static periodic-reminder + artifact-pool-ready + edge-artifact-required (per-RSI-loop) |
-| `rig watchdog` (daemon-shipped, v0.2.0 Phase C) | SQLite-backed scheduler; survives daemon restart | `periodic-reminder` / `artifact-pool-ready` / `edge-artifact-required` / `workflow-keepalive` (Phase D — reads workflow_instances directly) |
+## Active surface
 
 Daemon `rig watchdog` is the active host coordination surface for new
 work. History records only loud evaluations (`sent` / `terminal`);

package/daemon/context-packs/skills/core/watchdog/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "watchdog"
-version: "0.5.5"
+version: "0.5.7"
+taxonomy: "skills"
 purpose: "Use when configuring `rig watchdog` policies, authoring wake/refocus/alignment-checkpoint messages, or choosing the right intervention level for a stale-owner situation. The 3-level continuity-check stack (wake / refocus / alignment-checkpoint), the discipline that prevents cadence pollution and bureaucracy theater, and the artifact-pool loop-edge pattern for evidence-aware waking."
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/delegating-work/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: delegating-work
+description: "Use when you have a task and must decide WHO does it — yourself, a spawned subagent, or another agent in the topology that already holds the context. The rule: how much would a blank slate have to read in to do this correctly? A lot → route to a context-holding agent; a little → subagent; unsure → a real agent or yourself. NOT the mechanics of fanning out (that's dispatching-parallel-agents / subagent-driven-development) — this is the who/whether decision, and the failure mode that makes teams abandon subagents."
+metadata:
+  openrig:
+    stage: field-captured
+---
+
+# Delegating work — who should do this task?
+
+## The core question: context performance
+Getting work done well is a context problem. The agent best suited to a task is **the one who already holds the context that task requires.** Before you spawn a subagent or grind it out yourself, ask who that is.
+
+## The decision
+**Ask: how much would a blank slate have to read in before it could do this correctly?**
+
+- **A lot to read in → route to a real agent in the topology that already holds it.** This is what the role structure is FOR — reviewers, QA, implementers who have been on a project over time. An agent that already understands the work produces a better, safer result than any amount of briefing.
+- **A little — a prompt plus light grounding is enough → spawn a subagent.**
+- **Genuinely unsure → err toward a real agent, or do it yourself.**
+
+## Subagents are underused — reach for them far more
+For self-contained work that is fully specifiable in the prompt, spawn a subagent instead of spending your own context: tracing, research, grounding passes, summarizing, scanning log files, searching, fetching, web search, mechanical extraction with citations. This is the common shape and it is under-used.
+
+## The failure mode — the part that matters most
+**Subagents start as blank slates, and you cannot anticipate everything they need to know.** Give one a task where there is a lot to understand and it will have blind spots it does not know it has — it will complete the task and **return a false conclusion**, not from weakness but because it lacked the context to know what "correct" even looked like.
+
+This is the unknown-unknowns problem, and it is the single most common subagent failure: **a poorly-contextualized summary is worse than no summary, because it arrives looking like an answer.** Overreliance on subagents for context-heavy work causes more problems than it solves — and a team burned by it stops using subagents at all, which is the wrong correction. The fix is not "avoid subagents"; it is "match the task to the context it needs."
+
+## The practical test
+Before delegating to a blank slate, ask: **would a wrong-but-plausible answer here be detectable?** If the requester cannot check the result against something they already know — a citation they can open, a count they can re-run — the blind-spot risk is unacceptable, and that task belongs with an agent that holds the context.
+
+## Worked examples
+- **GOOD (→ subagent):** extract how four apps implement a UI mechanism, with `file:line` citations and an explicit instruction to report facts, not recommendations. Self-contained; the requester can verify the citations.
+- **BAD to delegate blind (→ routed to the context-holder):** an independent security re-sweep of a rewritten git branch, where knowing which commit range must stay byte-identical, and that "lightly obfuscated real values" is the thing to hunt, takes a paragraph to explain and one sentence to get wrong. It went to the agent already holding the context.
+
+## It generalizes
+This is really **"route work to whoever holds the context,"** with subagents as the option for work that needs none. The audience is **every agent** — implementers and QA seats make this call as much as orchestrators do.
+
+## Once you've decided
+- Decided on subagents for 2+ independent tasks → `dispatching-parallel-agents` (the fan-out mechanics).
+- Subagents executing a plan's independent tasks → `subagent-driven-development`.
+- Routing to a real agent you will direct over multiple rounds → `directing-partner-agents`.
+- The right context-holder is the human → `human-in-the-loop`.

package/daemon/context-packs/skills/delegating-work/manifest.yaml

@@ -0,0 +1,10 @@
+# GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
+# Package-time projection of a canonical skill; regenerated every build.
+name: "delegating-work"
+version: "0.5.7"
+taxonomy: "skills"
+purpose: "Use when you have a task and must decide WHO does it — yourself, a spawned subagent, or another agent in the topology that already holds the context. The rule: how much would a blank slate have to read in to do this correctly? A lot → route to a context-holding agent; a little → subagent; unsure → a real agent or yourself. NOT the mechanics of fanning out (that's dispatching-parallel-agents / subagent-driven-development) — this is the who/whether decision, and the failure mode that makes teams a"
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "Use when you have a task and must decide WHO does it — yourself, a spawned subagent, or another agent in the topology that already holds the context. The rule: how much would a blank slate have to read in to do this correctly? A lot → route to a context-holding agent; a little → subagent; unsure → a real agent or yourself. NOT the mechanics of fanning out (that's dispatching-parallel-agents / subagent-driven-development) — this is the who/whether decision, and the failure mode that makes teams a"