@femtomc/mu-agent 26.2.106 → 26.2.108

package/package.json

@@ -1,35 +1,35 @@
 {
-  "name": "@femtomc/mu-agent",
-  "version": "26.2.106",
-  "description": "Shared operator runtime for mu assistant sessions and serve extensions.",
-  "keywords": [
-    "mu",
-    "agent",
-    "runtime",
-    "chat",
-    "extensions"
-  ],
-  "type": "module",
-  "main": "./dist/index.js",
-  "types": "./dist/index.d.ts",
-  "exports": {
-    ".": {
-      "types": "./dist/index.d.ts",
-      "default": "./dist/index.js"
-    }
-  },
-  "files": [
-    "dist/**",
-    "assets/**",
-    "prompts/**",
-    "themes/**"
-  ],
-  "dependencies": {
-    "@femtomc/mu-core": "26.2.106",
-    "@mariozechner/pi-agent-core": "^0.54.2",
-    "@mariozechner/pi-ai": "^0.54.2",
-    "@mariozechner/pi-coding-agent": "^0.54.2",
-    "@mariozechner/pi-tui": "^0.54.2",
-    "zod": "^4.1.9"
-  }
+	"name": "@femtomc/mu-agent",
+	"version": "26.2.108",
+	"description": "Shared operator runtime for mu assistant sessions and serve extensions.",
+	"keywords": [
+		"mu",
+		"agent",
+		"runtime",
+		"chat",
+		"extensions"
+	],
+	"type": "module",
+	"main": "./dist/index.js",
+	"types": "./dist/index.d.ts",
+	"exports": {
+		".": {
+			"types": "./dist/index.d.ts",
+			"default": "./dist/index.js"
+		}
+	},
+	"files": [
+		"dist/**",
+		"assets/**",
+		"prompts/**",
+		"themes/**"
+	],
+	"dependencies": {
+		"@femtomc/mu-core": "26.2.108",
+		"@mariozechner/pi-agent-core": "^0.54.2",
+		"@mariozechner/pi-ai": "^0.54.2",
+		"@mariozechner/pi-coding-agent": "^0.54.2",
+		"@mariozechner/pi-tui": "^0.54.2",
+		"zod": "^4.1.9"
+	}
 }

package/prompts/skills/automation/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: automation
+description: "Meta-skill for durable and wall-clock automation. Routes to heartbeats and crons for recurring execution control."
+---
+
+# automation
+
+Use this meta-skill when the user wants recurring automation, scheduled execution, or scheduler diagnostics.
+
+## Subskills
+
+- `heartbeats` — durable wake-loop programs that run one bounded pass per tick.
+- `crons` — wall-clock scheduling (`at`, `every`, cron expressions) and lifecycle control.
+
+## Selection guide
+
+1. Use `heartbeats` for state-driven wake loops and short recurring supervision.
+2. Use `crons` for explicit wall-clock schedules and calendar-style timing.
+3. Pair automation with `subagents` stack skills (`protocol`, `execution`, etc.) when the workload is issue-DAG driven.
+
+## Common patterns
+
+- **Durable Orchestration**: Create a heartbeat (`heartbeats`) that runs one bounded `execution` pass per tick to supervise a `subagents` DAG over time, keeping the main chat clear.
+- **Scheduled Maintenance / Memory Update**: Set up a cron job (`crons`) to periodically invoke `memory` to rebuild indexes, fetch new docs, or clean up obsolete logs on a schedule.
+- **Continuous Diagnostics**: A heartbeat that periodically tails application logs or runs bounded check scripts locally. If a failure condition is met, the wake loop exits cleanly and notifies the user via the active channel.

package/prompts/skills/{crons → automation/crons}/SKILL.md

@@ -152,10 +152,10 @@ post concise summary, then exit.
 
 For DAG execution workloads, combine with:
 - `planning`
-- `orchestration`
+- `protocol`
 - `control-flow` (when explicit loop/termination policy is required)
 - `model-routing` (when per-issue model/provider/thinking policy is required)
-- `subagents`
+- `execution`
 - `heartbeats` (for short-cadence wake loops)
 
 ## Diagnostics and recovery

package/prompts/skills/{heartbeats → automation/heartbeats}/SKILL.md

@@ -145,10 +145,10 @@ packet mechanics, raw issue-ID lists). Include them only when diagnosing a block
 
 For hierarchical DAG execution, pair this skill with:
 - `planning`
-- `orchestration`
+- `protocol`
 - `control-flow` (when explicit loop/termination policy is required)
 - `model-routing` (when per-issue model/provider/thinking policy is required)
-- `subagents`
+- `execution`
 
 For wall-clock scheduling semantics (`at`, `every`, `cron`), use `crons`.
 

package/prompts/skills/core/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: core
+description: "Meta-skill for core mu operating primitives. Routes to mu, memory, tmux, and code-mode based on task shape."
+---
+
+# core
+
+Use this meta-skill when the user asks for general `mu` operation guidance and you need to pick the correct foundational skill.
+
+## Subskills
+
+- `mu` — default CLI-first operating workflow (inspect, mutate, verify, handoff).
+- `memory` — prior-context retrieval, timeline reconstruction, and memory-index maintenance.
+- `tmux` — persistent terminal/session substrate for bounded command execution and fan-out.
+- `code-mode` — tmux-backed REPL loops for iterative execution and context compression.
+
+## Selection guide
+
+1. Start with `mu` for most day-to-day operator work.
+2. Add `memory` when prior context or timeline anchors are required.
+3. Add `tmux` when durable shell state or parallel worker shells are needed.
+4. Add `code-mode` when solving by live execution is cheaper than chat-only reasoning.
+
+## Common patterns
+
+- **Bounded investigation**: Use `mu` commands (`get`, `read`, `health`) to inspect current state, then use `memory` to find "when did this last work?" before attempting a fix.
+- **Context compression**: If a user asks for complex debugging that involves running code and printing huge errors, route to `code-mode`. The agent can spin up a REPL, iterate on a fix offline, and return only the root cause to the chat.
+- **Parallel fan-out**: If a command takes a long time, or needs to run across multiple directories, route to `tmux` to spawn parallel worker shells, keep them running in the background, and periodically read their output.

package/prompts/skills/{code-mode → core/code-mode}/SKILL.md

@@ -112,7 +112,7 @@ tmux new-session -d -s mu-code-sh "bash --noprofile --norc -i"
 ## Integration with other mu skills
 
 - Use with `planning` when a plan step needs exploratory coding.
-- Use with `orchestration`/`subagents` by assigning one tmux session per worker.
+- Use with `protocol`/`execution` by assigning one tmux session per worker.
 - Use with `control-flow` for explicit retry/termination policy around code passes.
 - Use with `heartbeats`/`crons` when bounded code passes should run on schedule.
 

package/prompts/skills/{memory → core/memory}/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: memory
-description: "Runs cross-store memory retrieval and index maintenance workflows with bounded filters and timeline anchors. Use when querying historical context or repairing memory index health."
+description: "Runs cross-store memory retrieval and index maintenance workflows with bounded filters and timeline anchors. Use when querying prior context or repairing memory index health."
 ---
 
 # memory
 
-Use this skill when the user asks for historical context lookup, timeline reconstruction,
+Use this skill when the user asks for prior-context lookup, timeline reconstruction,
 or memory index diagnostics.
 
 ## Contents

package/prompts/skills/{mu → core/mu}/SKILL.md

@@ -14,6 +14,7 @@ run focused execution loops, and hand off to specialized skills when needed.
 - [CLI capability map](#cli-capability-map)
 - [Default bounded investigation loop](#default-bounded-investigation-loop)
 - [Common mutation and diagnostics patterns](#common-mutation-and-diagnostics-patterns)
+- [Reference `/answer` flow (mu_ui-only)](#reference-answer-flow-mu_ui-only)
 - [Session, serve, and one-shot surfaces](#session-serve-and-one-shot-surfaces)
 - [Durable automation handoff](#durable-automation-handoff)
 - [Evaluation scenarios](#evaluation-scenarios)
@@ -141,6 +142,37 @@ mu store tail cp_operator_turns --limit 20 --pretty
 mu replay <issue-id-or-log-path>
 ```
 
+## Reference `/answer` flow (mu_ui-only)
+
+Use this as the canonical interactive-skill pattern. Keep all behavior in skill logic and
+`mu_ui` documents/events; do not add adapter- or extension-specific branches.
+
+1. Publish the answer prompt as a `UiDoc` via `mu_ui`:
+
+```json
+{
+  "action": "set",
+  "doc": {
+    "v": 1,
+    "ui_id": "ui:answer",
+    "title": "Answer",
+    "components": [{ "kind": "text", "id": "prompt", "text": "Choose an answer", "metadata": {} }],
+    "actions": [
+      { "id": "answer_yes", "label": "Answer yes", "payload": { "choice": "yes" }, "metadata": { "command_text": "/answer yes" } },
+      { "id": "answer_no", "label": "Answer no", "payload": { "choice": "no" }, "metadata": { "command_text": "/answer no" } }
+    ],
+    "revision": { "id": "rev:answer:1", "version": 1 },
+    "updated_at_ms": 1
+  }
+}
+```
+
+2. On `/answer <choice>` input, validate choice, clear/remove `ui:answer` via `mu_ui`, then emit a
+   normal response.
+3. Keep revisions monotonic (`revision.version`) so reconnect/replay keeps the highest revision.
+4. Rely on `metadata.command_text` for cross-surface parity: TUI + messaging channels should route
+   the same `/answer ...` command text.
+
 ## Session, serve, and one-shot surfaces
 
 Primary interactive surface:
@@ -165,7 +197,15 @@ One-shot prompt (no durable session):
 mu exec --message "<task>" --json
 ```
 
-In attached terminal operator chat, `/mu` helpers are available (`/mu events`, `/mu hud ...`, `/mu help`).
+In attached terminal operator chat, `/mu` helpers are available (`/mu events`, `/mu ui status`, `/mu ui snapshot compact`, `/mu help`).
+
+Canonical visibility checks while running orchestrated work:
+
+```bash
+/mu ui status
+/mu ui snapshot compact
+/mu ui snapshot multiline
+```
 
 ## Durable automation handoff
 
@@ -177,10 +217,13 @@ mu cron --help
 ```
 
 When work is multi-step and issue-graph driven, use `planning` to shape the DAG,
-then `hud` for canonical HUD behavior, then `orchestration` to keep DAG
-semantics consistent, then `control-flow` for explicit loop/termination policy,
-then `model-routing` for per-issue provider/model/thinking selection overlays,
-then `subagents` for durable execution.
+then `protocol` to keep DAG semantics consistent, then `control-flow` for explicit
+loop/termination policy, then `model-routing` for per-issue provider/model/thinking
+selection overlays, then `execution` for durable execution supervision.
+Keep operator↔human communication mu_ui-first across these skills:
+- one non-interactive status doc per active profile (`metadata.profile.variant: "status"`)
+- separate interactive prompt docs for decisions (`metadata.command_text` actions)
+- explicit `mu_ui remove` teardown for resolved prompts and completed passes
 For REPL-driven exploration and context compression, use `code-mode`.
 For persistent terminal sessions and worker fan-out mechanics, use `tmux`.
 For recurring bounded automation loops, use `heartbeats`.
@@ -202,15 +245,15 @@ For wall-clock schedules (one-shot, interval, cron-expression), use `crons`.
 
 ## Escalation map
 
-- Historical context retrieval and index maintenance: **`memory`**
+- Prior-context retrieval and index maintenance: **`memory`**
 - Planning/decomposition and DAG review: **`planning`**
-- HUD contract/state updates across surfaces: **`hud`**
-- Shared DAG semantics for planning + execution: **`orchestration`**
+- mu_ui-first status/prompt communication patterns for DAG work: **`planning`**, **`execution`**, **`control-flow`**, **`model-routing`**
+- Shared DAG semantics for planning + execution: **`protocol`**
 - Loop/termination policy overlays (review gates, retries, escalation): **`control-flow`**
 - Per-issue model/provider/thinking selection overlays: **`model-routing`**
 - Live REPL execution and context engineering via tmux: **`code-mode`**
 - Persistent tmux session management + worker fan-out primitives: **`tmux`**
-- Durable multi-agent orchestration: **`subagents`**
+- Durable multi-agent orchestration: **`execution`**
 - Recurring bounded automation scheduling: **`heartbeats`**
 - Wall-clock scheduling workflows: **`crons`**
 - Messaging adapter onboarding:

package/prompts/skills/{tmux → core/tmux}/SKILL.md

@@ -131,7 +131,7 @@ Quick diagnostics checklist:
 ## Integration map
 
 - `code-mode`: tmux-backed REPL persistence and context engineering loops
-- `subagents`: tmux fan-out for parallel worker execution
+- `execution`: tmux fan-out for parallel worker execution
 - `heartbeats` / `crons`: schedule bounded passes that dispatch into tmux workers
 
 ## Evaluation scenarios

package/prompts/skills/messaging/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: messaging
+description: "Meta-skill for messaging/channel onboarding. Routes to setup-slack, setup-discord, setup-telegram, and setup-neovim."
+---
+
+# messaging
+
+Use this meta-skill when the user asks to onboard, repair, or verify channel messaging integration.
+
+## Subskills
+
+- `setup-slack` — Slack adapter setup, verification, and identity linking.
+- `setup-discord` — Discord adapter setup, verification, and identity linking.
+- `setup-telegram` — Telegram adapter setup, webhook flow, and identity linking.
+- `setup-neovim` — Neovim (`mu.nvim`) channel setup and identity linking.
+
+## Selection guide
+
+1. Pick the channel-specific setup skill that matches the target adapter.
+2. Run setup in an inspect -> patch config -> reload -> verify loop.
+3. Confirm identities and delivery behavior before declaring completion.
+
+## Common patterns
+
+- **Agent-First Bootstrap**: Rather than asking the user for all details upfront, start the correct `setup-*` skill to investigate the current `mu` config, generate generic adapter secrets locally (if possible), and only ask the user for web-portal-specific secrets (e.g. Discord bot tokens or Slack bot tokens).
+- **Verification Loop**: After rewriting the channel configuration dict, use the `setup-*` pattern to reload the mu controller (`mu cron ...`) and explicitly check the latest service logs or remote test (`/mu health`) to ensure connectivity works before ending the run.
+- **Identity Context Tying**: During adapter onboarding, link the local OS user identity with their remote Slack/Discord/Telegram IDs so that subsequent `mu exec` jobs running offline can accurately ping the user back.