@openrig/cli 0.5.8 → 0.5.10

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

@@ -1,7 +1,7 @@
 # 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.8"
+version: "0.5.10"
 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:

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

@@ -1,7 +1,7 @@
 # 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.8"
+version: "0.5.10"
 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:

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

@@ -1,7 +1,7 @@
 # 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.8"
+version: "0.5.10"
 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:

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

@@ -1,7 +1,7 @@
 # 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.8"
+version: "0.5.10"
 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:

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

@@ -1,7 +1,7 @@
 # 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.8"
+version: "0.5.10"
 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:

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

@@ -1,7 +1,7 @@
 # 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.8"
+version: "0.5.10"
 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:

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

@@ -1,7 +1,7 @@
 # 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.8"
+version: "0.5.10"
 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:

package/daemon/context-packs/skills/forming-an-openrig-mental-model/SKILL.md

@@ -24,8 +24,8 @@ metadata:
       - openrig-builder
       - openrig-architect
       - openrig-upgrade
-      - ai-dev-workflows
-      - software-for-agents
+      - agent-operated-workflows
+      - agent-operated-software
 ---
 
 # Forming an OpenRig Mental Model

package/daemon/context-packs/skills/forming-an-openrig-mental-model/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "forming-an-openrig-mental-model"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when the system around you does not make sense yet: you just booted into a seat and do not know how the pieces fit; someone said rig, pod, seat, fleet, topology, or slice and you are not certain what they mean here; you are unsure what kind of rig you are in or what it is for; you do not know how skills reach you or where context comes from; or you are about to act on a guess about how OpenRig works. Gives the runtime mental model fast, so you stop guessing."
 files:

package/daemon/context-packs/skills/loading-addressable-markdown/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "loading-addressable-markdown"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when a mission, slice, dashboard, or task references Markdown as path#h2-slug or path#h2-slug/h3-slug outside the OpenRig context-pack library."
 files:

package/daemon/context-packs/skills/mission-slice-sop/SKILL.md

@@ -17,11 +17,25 @@ Use this skill to actually **do** mission/slice work: track on the canonical fil
 
 **Full convention SSOT:** repo `docs/reference/sdlc-conventions.md`; installed `$OPENRIG_HOME/reference/sdlc-conventions.md`. This skill is the concise Part-A teaching surface and does not replace the full convention.
 
-## THIS IS THE LIGHT DEFAULT — read this before anything else
-
-**The default for any slice is the inner loop:** ground yourself → build → **test with your own eyes** → iterate → **ONE** full-breadth review at the end. That is the whole process. It is not a reduced form of a better process; it IS the process.
-
-**Part B is defined in the SSOT above and applies only when the human operator — or an orchestrator explicitly relaying that decision — assigns it to a named piece of work.** You may not select it yourself. If you believe something earns it, say so in one sentence and **continue on Part A** until told otherwise.
+## Resolve the work first
+
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
+
+The light inner loop is ground yourself → build → test with your own eyes →
+iterate → record and return the whole outcome. The builder may hold this check
+on a tiny change. Independent review runs only when selected, and once at an
+authored wave boundary rather than once per slice.
+
+Part B is defined in the conventions SSOT and runs only when explicitly assigned
+to named work. If you believe it is needed, state the reason to the owner and
+continue on the selected path until that choice changes.
 
 ## Proportionality — this SOP serves shipping; it is not the work itself
 

package/daemon/context-packs/skills/mission-slice-sop/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "mission-slice-sop"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when starting, building, handing off, restoring, or closing a mission or slice under the default lightweight SDLC."
 files:

package/daemon/context-packs/skills/openrig-operating-model/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-operating-model"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when you do not know WHERE something belongs: you learned a lesson and are unsure which file takes it; you are about to create a new doc, folder, or convention; you are asking \"should this be a skill, a note, or a chain file?\"; you inherited a seat and want to know what SHOULD exist; or you are about to duplicate knowledge that already has a home. Also the trace-to-root: how a seat orients by reading one filename at each level from where it stands up to the fleet."
 files:

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

@@ -175,7 +175,7 @@ section.
 
 ### Instantiate the canonical workspace scaffold
 
-Agent-actionable. Idempotent on existing dirs without `--force`.
+Agent-actionable. The operation is additive and preserves existing files.
 
 ```bash
 rig config init-workspace
@@ -187,19 +187,15 @@ rig config init-workspace --dry-run --json
 configured `workspace.root` (default `~/.openrig/workspace`):
 
 - `missions/` — release missions + slices
-- `artifacts/` — work artifacts produced inside the workspace
-- `evidence/` — non-dogfood evidence (release evidence, proof packets, etc.)
-- `progress/` — progress index + per-mission rails
-- `field-notes/` — operator + agent observations
-- `specs/` — spec library (rig + agent + workflow YAML lives here)
-- `dogfood-evidence/` — dogfood proof packets + run artifacts
-
-The scaffold seeds one example mission (`getting-started`) with multiple
-slices, and drops a workspace README.md + STEERING.md so a fresh install has
-browsable Project content. `--root <path>` targets a non-default root for
-this call; `--dry-run` reports what would be created without writing.
-`--force` overwrites existing FILES but never deletes
-directories — operator content is safe.
+- `exhaust/` — project-local coordination exhaust
+- `SPEC.md` — project intent
+- `project.yaml` — project catalog selections and mission root
+- `workspace.yaml` — project registration
+- `.gitignore` — local OpenRig state and exhaust exclusions
+
+`--root <path>` targets a non-default root for this call; `--dry-run` reports
+what would be created without writing. `--force` is deprecated compatibility
+and still preserves existing files.
 
 ### Redirect the workspace root
 
@@ -235,8 +231,8 @@ Agent-actionable. Same surface as the canonical scaffold above; the
 rig config init-workspace --root /path/to/new/workspace
 ```
 
-The command creates the root dir if missing (idempotent: existing root +
-populated subdirs is a no-op). Run
+The command additively creates any missing canonical entries and preserves
+every existing one; only a complete six-entry scaffold is a no-op. Run
 `rig workspace validate /path/to/new/workspace --json` after to confirm the
 contract holds.
 
@@ -721,6 +717,31 @@ rig env logs <rig>
 rig env down <rig>
 ```
 
+### Bounded agent self-scout
+
+Use the typed health projection before reading raw coordination history. The
+default query is the current seat; widen deliberately when the evidence points
+beyond it:
+
+```bash
+rig health --json
+rig health --rig <rig-id> --json
+rig health --instance --json
+rig health explain <finding-id> --json
+```
+
+Follow the returned stable finding ID and `suggestedInspection`. Use `explain`
+when the summary matters: it returns the same canonical record with its bounded
+window, freshness, literal detector rule, evidence references, and next
+inspection. Human output projects those same fields; it does not calculate a
+second score.
+
+An empty result means only that no records matched the bounded query. It is
+**not a healthy assertion**. Stale, unavailable, contradictory, and
+indeterminate evidence stays explicit. Never read raw SQLite for a self-scout,
+and never turn a finding into an acknowledgement, notification, queue row, or
+remediation automatically: `rig health` is strictly read-only.
+
 ## Transcript and Communication
 
 ### Transcript access

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

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-user"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when a specific `rig` command, subcommand, or flag is already known and you need its exact syntax, JSON shape, defaults, or error meaning. NOT for natural capability discovery, open-ended how-do-I questions, or choosing which OpenRig move applies."
 files:

package/daemon/context-packs/skills/orienting-to-an-inherited-seat/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "orienting-to-an-inherited-seat"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when you have just been primed into an EXISTING seat through a planned handover — a different agent retired and handed you the seat plus its earned context — and you need a world model of what just happened to you. Covers how a handover differs from compaction and from a fresh launch, the inherit-the-seat-not-the-identity rule, treating the handover packet as testimony you verify (and refusing stale ghost prompts, and verifying your OWN identity surfaces), why a seat is a COMPOUNDING LINEAGE"
 files:

package/daemon/context-packs/skills/pm/backlog-capture/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "backlog-capture"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Quickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication."
 files:

package/daemon/context-packs/skills/pm/context-builder/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "context-builder"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Gather and distill context from meetings, competitors, regulatory sources, and internal discussions. Produces background.md for a feature and updates shared context docs when new knowledge is discovered."
 files:

package/daemon/context-packs/skills/pm/exec-summary/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "exec-summary"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document."
 files:

package/daemon/context-packs/skills/pm/office-hours/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "office-hours"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "YC-style product validation using six forcing questions. Pressure-tests a feature idea before it becomes a requirement — ensuring real demand, a clear wedge, and evidence behind assumptions."
 files:

package/daemon/context-packs/skills/pm/plan-review/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "plan-review"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Multi-perspective review of a feature plan or requirements doc before development begins. Evaluates from strategy, design/UX, and engineering angles to catch gaps early."
 files:

package/daemon/context-packs/skills/pm/requirements-writer/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "requirements-writer"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when converting PM intake into a slice SPEC.md with observable acceptance outcomes, explicit scope, and advisory sibling build dependencies."
 files:

package/daemon/context-packs/skills/pm/ui-mockup/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "ui-mockup"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Create UI mockups at three fidelity levels — ASCII wireframes for quick iteration, standalone HTML mockups for delivery with requirements, and live prototypes for interaction testing."
 files:

package/daemon/context-packs/skills/pods/development-team/SKILL.md

@@ -1,156 +1,57 @@
 ---
 name: development-team
-description: How the development pod coordinates implementation, QA, and design without skipping gates.
+description: Use when a development pod begins or hands off implementation, QA, or design work.
 ---
 
 # Development Team
 
-You are part of the development pod. Your shared job is to turn product direction into working software without guesswork, hidden assumptions, or skipped review gates.
+The pod turns the assigned user outcome into working software. Builders, QA and
+designers are capabilities; neighboring roles may be held by one seat unless
+independence was explicitly selected.
 
-## Startup sequence
+## Start from the work
 
-Before the pod starts real implementation:
-- load the packaged skills named in your role startup checklist
-- run `rig whoami --json`
-- confirm who is playing implementer, QA, and design in this run
-- wait for the orchestrator's real assignment instead of freelancing off a partial guess
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
 
-The development pod should feel like a real working pod, not three isolated agents improvising alone.
+## Build and verify
 
-## Pod shape
+Clarify consequential uncertainty, inspect the existing seam, then complete one
+coherent outcome. Reproduce a defect before repairing it; use tests that distinguish
+the failure and verify through the public surface. Keep chunks as large as the
+outcome and file territory permit. TDD is a feedback loop, not a two-seat protocol.
 
-The development pod may include:
-- an implementer who writes the change
-- a QA partner who gates every edit
-- a designer who clarifies product behavior and UX before implementation fills in the blanks
+The builder reports the exact candidate, changed behavior, commands and observed
+results, with remaining uncertainty. No universal pre-edit proposal, QA approval
+or post-edit gate is implied. When one is explicitly selected, honor its boundary
+and send the relevant evidence directly to its owner.
 
-Some starters only launch the implementer and QA. Others also launch a designer. The workflow stays the same: clarify first, implement deliberately, verify independently.
+## QA and design
 
-## Shared loop
+QA compares the delivered behavior with the actual contract. Read the diff and
+exercise the result; avoid tests that merely repeat the implementation. On a tiny
+change the builder may hold QA. Independent QA excludes the author when selected.
+A wave receives independent review at its authored boundary, not per slice.
 
-This is the default loop for product work:
+Design clarifies user flows and ambiguous behavior when the outcome needs it.
+Browser and dogfood skills load for a relevant UI journey, not every task. During
+assigned dogfood, fix-and-retest only within the granted scope; a read-only
+assignment stays read-only. If a tester becomes an author, preserve that attribution
+when independent evaluation is required.
 
-```
-1. Clarify the work and the acceptance criteria
-2. Implementer sends a pre-edit proposal to QA
-3. QA approves or rejects with specifics
-4. Implementer changes code with TDD
-5. Implementer sends the diff and verification output back to QA
-6. QA approves or rejects with specifics
-7. If commit authority is enabled, the implementer may commit
-8. If commit authority is not enabled, stop at a QA-approved working tree and report that state clearly
-```
+## Blockers and return
 
-Skip no gates. If the task is ambiguous, resolve the ambiguity before editing.
+Use `systematic-debugging` for an unexpected failure and
+`verification-before-completion` before claiming success. A permission prompt is
+a concrete blocker; report the command and consequence instead of labeling it
+progress. A missing decision goes to the owner who can settle it.
 
-**Chunk size points up — keep TDD's shape, not its ping-pong cadence (2026-08).** Frontier agents handle
-large, long-horizon, goal-oriented chunks — an hour-plus of complex work — without fragmenting. So don't
-default to tiny pieces: **keep TDD's *shape* (two sets of eyes, the guard structure, red before green)
-but treat chunk size and cadence as a configured LEVER, not a habit.** Classic small back-and-forth
-ping-pong is unnecessary overhead when the loop's own gates (QA, review, guards) already bound a larger
-chunk's risk. The sweet spot is task-dependent, much larger than it used to be, and rising. See
-`test-driven-development` for the shape that stays fixed.
-
-## What the implementer must hand QA
-
-Pre-edit proposal should include:
-- the files expected to change
-- the behavior or acceptance criteria being targeted
-- the first failing test or verification step
-- any likely edge cases or invariants
-
-Post-edit review bundle should include:
-- what changed
-- the actual verification commands run
-- the result of those commands
-- any remaining uncertainty or follow-up risk
-
-QA should not have to reverse-engineer what the implementer thought they were doing.
-
-## Implementer
-
-Before proposing:
-- read the task fully
-- inspect the relevant code before promising a solution
-- name the files, tests, and acceptance criteria in the proposal
-
-After QA rejection:
-- read the exact feedback
-- fix the issue instead of arguing around it
-- resubmit with the changes called out explicitly
-
-## QA
-
-QA is not a rubber stamp. QA is a product voice — not just a test gate.
-
-When reviewing a proposal:
-- reject if the scope is wrong
-- check whether the planned tests actually prove the contract
-- flag hidden risks and missing failure cases
-
-When reviewing a diff:
-- read the actual code, not just the summary
-- verify independently when possible
-- if you cannot verify independently, require real output in the review bundle and inspect it critically
-
-If the implementer stalls on a permission or approval prompt, call that out immediately. Do not treat a blocked pane as finished implementation.
-
-### QA dogfood mode
-
-When QA is dogfooding (testing existing features rather than gating new code), QA works solo with full autonomy:
-- find issues AND fix them in a loop
-- test the fix, then move to the next issue
-- only escalate architecture-level concerns to the orchestrator
-- do not wait for approval to fix obvious bugs during dogfood
-- report findings to the chatroom so the rig has visibility
-
-### QA as a product voice
-
-QA sees the product from the user's perspective. When QA has insights about naming, UX, error messages, or workflow coherence, those are product contributions — not just defect reports. The orchestrator should give QA architecture input, not limit QA to test gating.
-
-## Designer
-
-When present, the designer should work ahead of implementation:
-- turn vague goals into concrete flows, states, copy, and interaction choices
-- surface edge cases before engineering has to guess
-- review built results for coherence, not just visual polish
-
-The designer is part of the development pod, not a decorative sidecar.
-
-## Browser testing and dogfood tools
-
-The development pod has access to browser automation and structured dogfood testing tools:
-
-- **`agent-browser`** — browser automation CLI. Navigate to the daemon UI, snapshot interactive elements, take annotated screenshots, record repro videos. Use `agent-browser open <url>`, `agent-browser snapshot -i`, `agent-browser screenshot --annotate`.
-- **`dogfood`** — structured exploratory testing workflow. Produces a report with screenshots, repro videos, and step-by-step evidence for every finding.
-
-QA typically drives browser and dogfood testing, but both impl and QA should know these tools exist and can use them. When dogfooding UI:
-1. Load `/agent-browser` and `/dogfood`
-2. Open the daemon UI: `agent-browser open http://127.0.0.1:7433`
-3. Systematically explore surfaces, take screenshots as proof
-4. Report findings using the PASS/FAIL/GAP format to the chatroom
-
-## When the pod is blocked
-
-If the blocker is:
-- ambiguity: pull in design or ask the orchestrator for clarification
-- failing tests / unexpected behavior: use `systematic-debugging`
-- code changes: use `test-driven-development`
-- completion claims: use `verification-before-completion`
-
-Do not hand-wave around blockers. Name them and route them.
-
-## Communication
-
-- Pre-edit proposal: `rig send <qa-session> "PRE-EDIT: ..." --verify`
-- Review bundle: `rig send <qa-session> "REVIEW BUNDLE: ..." --verify`
-- Design clarification: `rig send <design-session> "Need product/design input on ..." --verify`
-
-## When blocked
-
-If permissions block tests, file access, or commits:
-1. identify the exact blocked command
-2. tell the human what that prevents
-3. continue with the work you can still do
-
-Do not silently stall. Do not pretend blocked verification is complete.
+Return the candidate and evidence through the selected handoff. Do not create
+obligations just to keep an idle QA, guard or reviewer occupied. Quality is a
+working product with honest evidence, not the number of transfers.

package/daemon/context-packs/skills/pods/development-team/manifest.yaml

@@ -1,10 +1,10 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "development-team"
-version: "0.5.8"
+version: "0.5.10"
 taxonomy: "skills"
-purpose: "How the development pod coordinates implementation, QA, and design without skipping gates."
+purpose: "Use when a development pod begins or hands off implementation, QA, or design work."
 files:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "How the development pod coordinates implementation, QA, and design without skipping gates."
+    summary: "Use when a development pod begins or hands off implementation, QA, or design work."