@femtomc/mu-agent 26.2.106 → 26.2.107

package/prompts/skills/{model-routing → subagents/model-routing}/SKILL.md

@@ -6,7 +6,7 @@ description: "Adds a model-selection overlay for issue DAG execution, recommendi
 # model-routing
 
 Use this skill when execution should choose different models for different issue
-kinds (for example code vs docs), while preserving orchestration protocol
+kinds (for example code vs docs), while preserving protocol
 semantics.
 
 ## Contents
@@ -14,6 +14,7 @@ semantics.
 - [Purpose](#purpose)
 - [Required dependencies](#required-dependencies)
 - [Core contract](#core-contract)
+- [Quality profile policy (high-stakes orchestration)](#quality-profile-policy-high-stakes-orchestration)
 - [Overlay identity (`route:model-routing-v1`)](#overlay-identity-routemodel-routing-v1)
 - [Tag vocabulary](#tag-vocabulary)
 - [Recommendation packet contract](#recommendation-packet-contract)
@@ -27,8 +28,8 @@ semantics.
 
 ## Purpose
 
-Model-routing policies are overlays. They do not replace `orchestration`
-protocol semantics.
+Model-routing policies are overlays. They do not replace protocol
+semantics.
 
 Examples:
 - use a strong coding model for implementation leaves
@@ -40,8 +41,8 @@ Examples:
 
 Load these skills before applying model-routing policies:
 
-- `orchestration` (protocol primitives/invariants)
-- `subagents` (durable execution runtime)
+- `protocol` (protocol primitives/invariants)
+- `execution` (durable execution runtime)
 - `heartbeats` and/or `crons` (scheduler clock)
 - `hud` (required visibility/handoff surface)
 - `control-flow` (optional; when loop/termination overlays are also active)
@@ -71,6 +72,25 @@ Load these skills before applying model-routing policies:
    - Use `mu exec --provider/--model/--thinking` or `mu turn ...` overrides.
    - Avoid changing workspace-global operator defaults for per-issue routing.
 
+## Quality profile policy (high-stakes orchestration)
+
+For protocol/runtime/schema/cross-adapter work, apply an explicit quality floor.
+Do not rely on implicit defaults.
+
+Recommended high-stakes profile:
+
+- provider: `openai-codex`
+- model: `gpt-5.3-codex`
+- thinking: `xhigh`
+
+Required guardrails:
+
+1. Always pass explicit `--provider --model --thinking` when launching workers.
+2. Do not use mini/fast profiles for root-close decisions, acceptance-signoff,
+   or architecture-contract issues unless the user explicitly requests it.
+3. If authenticated capability for the high-stakes profile is unavailable,
+   emit a `ROUTE_FALLBACK` packet that explains the downgrade rationale.
+
 ## Overlay identity (`route:model-routing-v1`)
 
 - Tag scope root (or selected subtree root) with: `route:model-routing-v1`
@@ -151,6 +171,13 @@ Optional root-level packet for custom preferences:
 ROUTE_POLICY:
 {
   "version": "route:model-routing-v1",
+  "quality_profiles": {
+    "orchestration_critical": {
+      "provider": "openai-codex",
+      "model": "gpt-5.3-codex",
+      "thinking": "xhigh"
+    }
+  },
   "task_preferences": {
     "code": [
       { "provider": "openai-codex", "model": "gpt-5.3-codex", "thinking": "xhigh" }
@@ -218,7 +245,7 @@ For one-shot execution:
 
 ```bash
 mu exec --provider <provider> --model <model> --thinking <thinking> \
-  "Use skills subagents, orchestration, model-routing, and hud. Work issue <issue-id>."
+  "Use skills subagents, protocol, execution, model-routing, and hud. Work issue <issue-id>."
 ```
 
 For existing session turn:
@@ -257,7 +284,7 @@ When planning a routed subtree:
 2. Tag executable nodes with task/depth/budget intent.
 3. Record any hard constraints (modality/context) in issue body or forum packet.
 4. Optionally add root `ROUTE_POLICY` preferences.
-5. Ensure DAG remains valid under `orchestration` invariants:
+5. Ensure DAG remains valid under `protocol` invariants:
    - `mu issues ready --root <root-id> --tag proto:hierarchical-work-v1 --pretty`
    - `mu issues validate <root-id>`
 
@@ -279,7 +306,7 @@ Per orchestrator tick:
 Reusable heartbeat prompt fragment:
 
 ```text
-Use skills orchestration, model-routing, subagents, and hud.
+Use skills subagents, protocol, execution, model-routing, and hud.
 For root <root-id>, enforce route:model-routing-v1.
 Run exactly one bounded routing/orchestration transition pass: compute or validate
 one issue's model recommendation from live `mu control harness` capabilities,

package/prompts/skills/{planning → subagents/planning}/SKILL.md

@@ -3,7 +3,7 @@ name: planning
 description: "Builds and refines issue-DAG plans using the planning HUD and approval loops. Use when the user asks for planning, decomposition, sequencing, or plan review."
 ---
 
-# Planning
+# planning
 
 Use this skill when the user asks for planning, decomposition, or a staged execution roadmap.
 
@@ -45,8 +45,8 @@ Before emitting or mutating planning HUD state, load **`hud`** and follow its ca
 
 ## Shared protocol dependency
 
-This skill plans DAGs for execution by `subagents`, so planning must follow the
-shared protocol in **`orchestration`**.
+This skill plans DAGs for execution by `execution`, so planning must follow the
+shared protocol in **`protocol`**.
 
 Before creating or reshaping DAG nodes, load that skill and use its canonical:
 
@@ -59,12 +59,12 @@ Do not invent alternate protocol names or tag schemas.
 
 If the user asks for explicit loop/termination behavior (for example review-gated
 retry rounds), load **`control-flow`** and encode policy via `flow:*` overlays
-without changing orchestration protocol semantics.
+without changing protocol semantics.
 
 If the user asks for per-issue model/provider/thinking recommendations based on
 live harness capabilities, load **`model-routing`** and encode policy via
 `route:*` overlays plus route packets (for example `ROUTE_POLICY`) without
-changing orchestration protocol semantics.
+changing protocol semantics.
 
 ## Core contract
 
@@ -96,10 +96,10 @@ changing orchestration protocol semantics.
 
 6. **After user approval, ask user about next steps**
    - On user acceptance of the plan, teardown planning HUD ownership.
-   - If handing off to another HUD-owning skill (for example `subagents`), remove
+   - If handing off to another HUD-owning skill (for example `execution`), remove
      `hud_id:"planning"` and keep HUD on for the next skill.
    - If no next HUD-owning skill starts immediately, remove planning doc and turn HUD off.
-   - Read the `subagents` skill and offer to supervise subagents to execute the plan.
+   - Read the `execution` skill and offer to supervise execution to realize the plan.
 
 ## Suggested workflow
 

package/prompts/skills/{orchestration → subagents/protocol}/SKILL.md

@@ -1,14 +1,12 @@
 ---
-name: orchestration
-description: "Defines the shared planning/execution orchestration protocol for issue-DAG work. Use when creating, validating, or executing protocol-driven DAG work."
+name: protocol
+description: "Defines the shared planning/execution protocol for issue-DAG work. Use when creating, validating, or executing protocol-driven DAG work."
 ---
 
-# orchestration
+# protocol
 
 Use this skill when work should flow through one shared protocol from planning to execution.
 
-This skill supersedes the previous `hierarchical-work-protocol` skill name.
-
 ## Contents
 
 - [Protocol identity](#protocol-identity)
@@ -26,7 +24,6 @@ This skill supersedes the previous `hierarchical-work-protocol` skill name.
 - Protocol ID: `hierarchical-work.protocol/v1`
 - Required issue tag on all protocol nodes: `proto:hierarchical-work-v1`
 
-This system does **not** use backward-compatibility aliases for older protocol names.
 Use only the protocol ID and tag above.
 
 ## Canonical tags and node roles
@@ -70,7 +67,7 @@ Node role rules:
 Policy overlays are layered on top of this protocol and should not redefine
 protocol primitives or `kind:*` semantics.
 
-- Keep orchestration protocol tags/kinds as source-of-truth for structure.
+- Keep protocol tags/kinds as source-of-truth for structure.
 - Represent policy-specific behavior with overlay tags/metadata:
   - loop/termination policy (for example review gates, retry rounds,
     escalation thresholds): `flow:*`
@@ -192,7 +189,7 @@ mu issues dep <step-a> blocks <step-b>
 
 ## Planning handoff contract
 
-Before handoff from planning to subagent orchestration:
+Before handoff from planning to execution supervision:
 
 1. Root exists and is tagged `node:root`, `kind:root`, `proto:hierarchical-work-v1`.
 2. Every in-scope node carries `proto:hierarchical-work-v1`.
@@ -212,7 +209,7 @@ mu issues validate <root-id>
 Worker/orchestrator passes always choose one primitive at a time:
 
 1. `read_tree`
-2. Choose one primitive (`ask` | `expand` | `complete` | orchestration primitive)
+2. Choose one primitive (`ask` | `expand` | `complete` | protocol primitive)
 3. Apply
 4. Verify (`get`, `children`, `ready`, `validate`)
 5. Log human-facing progress to forum as a titled narrative update (context -> milestone moved -> impact -> overall progress -> next), using the reusable status-voice style from `heartbeats`
@@ -245,7 +242,7 @@ mu forum post issue:"$goal_id" -m "<goal brief + acceptance criteria>" --author
 
 1. **Planning-to-execution continuity**
    - Setup: a freshly planned DAG.
-   - Expected: all nodes satisfy protocol tag/kind/context rules and can be consumed by subagents without re-shaping.
+   - Expected: all nodes satisfy protocol tag/kind/context rules and can be consumed by `execution` without re-shaping.
 
 2. **Decomposition with synthesis fan-in**
    - Setup: worker expands a complex node.

package/prompts/skills/writing/SKILL.md

@@ -14,6 +14,7 @@ Use this skill when asked to write, edit, or review technical prose. This includ
 - [Common patterns by document type](#common-patterns-by-document-type)
 - [Editing and review workflow](#editing-and-review-workflow)
 - [Evaluation scenarios](#evaluation-scenarios)
+- [Quality bar](#quality-bar)
 
 ## Core contract