@femtomc/mu-agent 26.2.84 → 26.2.85

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@femtomc/mu-agent",
-  "version": "26.2.84",
+  "version": "26.2.85",
   "description": "Shared agent runtime for mu assistant sessions, orchestration roles, and serve extensions.",
   "keywords": [
     "mu",
@@ -24,7 +24,7 @@
     "themes/**"
   ],
   "dependencies": {
-    "@femtomc/mu-core": "26.2.84",
+    "@femtomc/mu-core": "26.2.85",
     "@mariozechner/pi-agent-core": "^0.53.0",
     "@mariozechner/pi-ai": "^0.53.0",
     "@mariozechner/pi-coding-agent": "^0.53.0",

package/prompts/skills/planning/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: planning
+description: Investigate first, then propose a concrete issue plan and refine it with the user until approved.
+---
+
+# Planning
+
+Use this skill when the user asks for planning, decomposition, or a staged execution roadmap.
+
+## Core contract
+
+1. **Investigate first**
+   - Read relevant code/docs/state before proposing work.
+   - Avoid speculative plans when evidence is cheap to gather.
+
+2. **Materialize the plan in mu issues**
+   - Create a root planning issue and concrete child issues.
+   - Encode dependencies so the DAG reflects execution order.
+   - Add clear titles, scope, acceptance criteria, and role tags.
+
+3. **Present the plan to the user**
+   - Summarize goals, sequencing, risks, and tradeoffs.
+   - Include issue IDs so the user can reference exact nodes.
+
+4. **Iterate until user approval**
+   - Treat user feedback as first-class constraints.
+   - Update issues/dependencies and re-present deltas.
+   - Do not begin broad execution until the user signals satisfaction.
+
+## Suggested workflow
+
+### A) Investigation pass
+
+```bash
+mu status --pretty
+mu issues list --status open --limit 50 --pretty
+mu forum read user:context --limit 50 --pretty
+mu memory search --query "<topic>" --limit 30
+```
+
+Also inspect repo files directly (read/bash) for implementation constraints.
+
+### B) Draft DAG in mu-issue
+
+```bash
+# 1) Create root planning issue
+mu issues create "<Goal>" --body "<scope + success criteria>" --tag node:root --role orchestrator --pretty
+
+# 2) Create child work items
+mu issues create "<Subtask A>" --parent <root-id> --role worker --priority 2 --pretty
+mu issues create "<Subtask B>" --parent <root-id> --role worker --priority 2 --pretty
+
+# 3) Add dependency edges where needed
+mu issues dep <child-a-id> blocks <child-b-id>
+
+# 4) Validate ready set
+mu issues ready --root <root-id> --pretty
+```
+
+### C) Plan presentation template
+
+- Objective
+- Assumptions and constraints discovered in investigation
+- Proposed issue DAG (IDs + titles + ordering)
+- Risks and mitigations
+- Open questions for user approval
+
+### D) Revision loop
+
+- Apply feedback with `mu issues update` / `mu issues dep` / additional issues.
+- Re-run `mu issues ready --root <root-id> --pretty`.
+- Present a concise diff of what changed and why.
+
+## Quality bar
+
+- Every issue should be actionable and testable.
+- Keep tasks small enough to complete in one focused pass.
+- Explicitly call out uncertain assumptions for user confirmation.
+- Prefer reversible plans and incremental checkpoints.

package/prompts/skills/reviewer/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: reviewer
+description: Run a dedicated reviewer pass in tmux and return a strict verdict with evidence.
+---
+
+# Reviewer
+
+Use this skill when you want a separate reviewer lane that audits work before finalizing.
+
+## Goals
+
+- Isolate review from implementation context.
+- Require explicit pass/fail criteria.
+- Produce concrete evidence (tests, diffs, traces) for the verdict.
+
+## Reviewer lane pattern
+
+```bash
+run_id="$(date +%Y%m%d-%H%M%S)"
+review_session="mu-review-${run_id}"
+
+# Start a dedicated reviewer session
+# (Use the same repo and server port as the main workflow.)
+tmux new-session -d -s "$review_session" \
+  "cd '$PWD' && mu session --new --port 3000 ; rc=\$?; echo __MU_DONE__:\$rc"
+```
+
+Then inject a strict reviewer prompt in that tmux pane (attach or send keys) with:
+
+- Scope under review
+- Acceptance criteria
+- Required checks (build/test/lint, edge cases, regressions)
+- Required output format: `PASS` or `FAIL`, plus blockers and fixes
+
+## Suggested reviewer prompt shape
+
+- "Act as a strict reviewer. Validate only against these acceptance criteria..."
+- "Run the necessary checks and cite concrete evidence."
+- "Return: verdict, evidence, risk list, and required fixes."
+
+## Monitoring and collection
+
+```bash
+tmux capture-pane -pt "$review_session" -S -300
+tmux attach -t "$review_session"
+```
+
+If the reviewer leaves open questions, ask follow-up turns in the same reviewer session:
+
+```bash
+mu session list --json --pretty
+mu turn --session-kind operator --session-id <session-id> --body "Clarify blocker #2"
+```
+
+Use `--session-kind operator` for terminal/tmux reviewer sessions.
+If omitted, `mu turn` defaults to control-plane operator sessions (`cp_operator`).
+
+Once complete, summarize reviewer findings back into the main workflow and create follow-up issues for each blocker.
+
+## Safety rules
+
+- Reviewer must not silently relax acceptance criteria.
+- Prefer failing with explicit evidence over guessing.
+- Keep reviewer output actionable (file paths, commands, failing checks).
+- Close/kill temporary tmux sessions after review.

package/prompts/skills/subagents/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: subagents
+description: Break a task into independent parts and dispatch mu subagents in tmux sessions.
+---
+
+# Subagents
+
+Use this skill when work can be split into independent shards and run concurrently.
+
+## When to use
+
+- The task can be decomposed into parallelizable parts.
+- Each shard can be specified with a clear prompt and bounded outcome.
+- You need a durable terminal surface to inspect each shard separately.
+
+## Workflow
+
+1. Decompose into 2–4 independent subtasks with explicit deliverables.
+2. Launch one detached tmux session per subtask.
+3. Run a `mu` invocation in each session.
+4. Monitor each pane, then reconcile outputs into one final synthesis.
+
+## Launch pattern
+
+```bash
+run_id="$(date +%Y%m%d-%H%M%S)"
+
+# Optional: keep one shared server alive for all shards
+mu serve --port 3000
+
+# In another terminal, dispatch shards
+for shard in 1 2 3; do
+  session="mu-sub-${run_id}-${shard}"
+  tmux new-session -d -s "$session" \
+    "cd '$PWD' && mu run 'SUBTASK_PROMPT_${shard}' ; rc=\$?; echo __MU_DONE__:\$rc"
+done
+```
+
+If you need non-interactive queueing, use `mu runs start ...` in tmux windows instead of `mu run ...`.
+
+## Monitoring
+
+```bash
+tmux ls | rg '^mu-sub-'
+tmux capture-pane -pt mu-sub-<run-id>-1 -S -200
+tmux attach -t mu-sub-<run-id>-1
+```
+
+## Handoffs and follow-up turns
+
+When a subagent session already exists, ask direct follow-ups in that same session:
+
+```bash
+mu session list --json --pretty
+mu turn --session-kind operator --session-id <session-id> --body "Follow-up question"
+```
+
+Use `--session-kind operator` for terminal/tmux subagent sessions.
+If omitted, `mu turn` defaults to control-plane operator sessions (`cp_operator`).
+
+## Reconciliation checklist
+
+- Collect outputs from each shard.
+- Identify conflicts or overlaps.
+- Produce one merged plan/result with explicit decisions.
+- Record any follow-up tasks in `mu issues` / `mu forum`.
+
+## Safety rules
+
+- Keep shard prompts scoped and explicit.
+- Prefer fewer, higher-quality shards over many noisy shards.
+- Do not overwrite unrelated files across shards.
+- Tear down temporary tmux sessions when done.