@femtomc/mu-agent 26.2.89 → 26.2.91

package/prompts/skills/subagents/SKILL.md

@@ -1,153 +1,274 @@
 ---
 name: subagents
-description: Break work into issue-tracked shards and dispatch mu subagents in tmux sessions.
+description: Orchestrate issue-driven subagent work with heartbeat supervision and tmux worker fan-out.
 ---
 
 # Subagents
 
-Use this skill when work can be split into independent shards and run concurrently.
+## Purpose (what this skill is for)
+
+Use this skill for **durable multi-agent orchestration**: work that must keep moving over time, not just one-shot execution.
+
+This skill combines `mu` primitives into one orchestration model:
+
+- `mu issues` = executable DAG, dependencies, lifecycle state
+- `mu forum` = durable task/result packets
+- `mu heartbeats` / `mu cron` = orchestrator wake cadence
+- `tmux` + `mu exec` = parallel worker execution
+- subagents HUD = observability/control board
+
+Protocol truth lives in **issues + forum**. HUD/tmux are execution and visibility surfaces.
 
 ## 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.
+- Work can be represented as issue-scoped deliverables with explicit outcomes.
+- Dependencies may unblock over time.
+- You want unattended progress between manual check-ins.
+
+## Success condition
+
+- Each executable issue is claimed, worked, and closed with an explicit outcome.
+- Results are posted in `issue:<id>` forum topics.
+- Root completion is validated via `mu issues validate <root-id>`.
+
+## Dispatch modes
+
+### 1) Heartbeat dispatch (orchestrator cadence)
+
+Use when you want the orchestration loop to keep running over time.
+
+Each heartbeat tick should run **one bounded control-loop pass**:
 
-## Workflow
+1. Read queue/tree state.
+2. Choose one primitive (`ask`, `expand`, `complete`, etc.).
+3. Apply one action.
+4. Verify state + log progress.
+5. Exit.
 
-1. Create a root issue and decompose into 2–4 actionable child issues in `mu issues`.
-2. Ensure each child has clear acceptance criteria and dependency edges.
-3. Launch one detached tmux session per ready child issue.
-4. Monitor both tmux sessions and issue queue state, then reconcile outputs.
+Heartbeat dispatch is the **orchestrator clock**. It should supervise/advance the graph, not run unbounded worker sessions.
 
-## Launch pattern
+### 2) tmux dispatch (parallel workers)
 
-Issue-first decomposition (required before dispatch):
+Use when multiple ready leaves should execute concurrently now.
+
+Spawn one tmux session per ready issue. Each worker should claim one issue, run one full issue loop, then exit.
+
+## Protocol: `subagents.protocol/v1` (how the skill executes)
+
+### Primitive: `read_tree`
+
+Before every mutation, inspect root + local node state:
 
 ```bash
-# Root issue
-mu issues create "Root: <goal>" --tag node:root --role orchestrator
+mu issues get <issue-id> --pretty
+mu issues children <issue-id> --pretty
+mu issues ready --root <root-id> --tag proto:subagents-v1 --pretty
+mu forum read issue:<issue-id> --limit 20 --pretty
+```
 
-# Child issues (repeat as needed)
-mu issues create "<child-1 deliverable>" --parent <root-id> --role worker --priority 2
-mu issues create "<child-2 deliverable>" --parent <root-id> --role worker --priority 2
+### Primitive: `claim`
 
-# Optional ordering constraints
-mu issues dep <child-1> blocks <child-2>
+Claim before doing work on an executable issue:
 
-# Verify queue before fan-out
-mu issues ready --root <root-id> --tag role:worker --pretty
+```bash
+mu issues claim <issue-id>
+mu forum post issue:<issue-id> -m "START: <plan for this pass>" --author operator
 ```
 
-Dispatch one tmux subagent per ready issue id:
+### Primitive: `spawn` (clean-context child)
+
+Create independent child tasks with scoped context:
 
 ```bash
-run_id="$(date +%Y%m%d-%H%M%S)"
+child_json="$(mu issues create "<title>" \
+  --parent <issue-id> \
+  --body "<prompt + acceptance criteria>" \
+  --tag proto:subagents-v1 \
+  --tag kind:spawn \
+  --tag ctx:clean \
+  --priority 2 \
+  --json)"
+child_id="$(echo "$child_json" | jq -r '.id')"
+mu forum post issue:"$child_id" -m "<task packet>" --author operator
+```
 
-# Optional: keep one shared server alive for all shards
-mu serve --port 3000
+Use dependencies to control timing:
 
-for issue_id in <issue-a> <issue-b> <issue-c>; do
-  session="mu-sub-${run_id}-${issue_id}"
-  tmux new-session -d -s "$session" \
-    "cd '$PWD' && mu exec 'Work issue ${issue_id}. First: mu issues claim ${issue_id}. Keep forum updates on issue:${issue_id}. Close when complete.' ; rc=\$?; echo __MU_DONE__:\$rc"
-done
+```bash
+mu issues dep <blocker-id> blocks <child-id>
 ```
 
-Use `mu exec` for lightweight one-shot subagent work.
-If you need queued orchestration runs, use `mu runs start ...` / `mu run ...` instead.
+### Primitive: `fork` (inherited-context child)
+
+Create analysis/synthesis children that depend on sibling outputs.
+Before creation, summarize dependency results from `mu forum read issue:<dep-id>`.
+Then create with `kind:fork` + `ctx:inherit`.
+
+### Primitive: `ask` (human input node)
 
-## Monitoring
+Represent user questions as first-class nodes:
 
 ```bash
-tmux ls | rg '^mu-sub-'
-tmux capture-pane -pt mu-sub-<run-id>-<issue-id> -S -200
-tmux attach -t mu-sub-<run-id>-<issue-id>
+ask_json="$(mu issues create "Question: <question>" \
+  --parent <issue-id> \
+  --tag proto:subagents-v1 \
+  --priority 1 \
+  --json)"
+ask_id="$(echo "$ask_json" | jq -r '.id')"
+mu issues update "$ask_id" \
+  --remove-tag node:agent \
+  --add-tag kind:ask \
+  --add-tag ctx:human \
+  --add-tag actor:user
+mu forum post issue:"$ask_id" \
+  -m "QUESTION: <question>\nOPTIONS: <list or free-form>\nReply in this topic, then close this issue." \
+  --author operator
+```
+
+If downstream work depends on the answer:
 
-# Issue queue visibility (same root used for dispatch)
-mu issues ready --root <root-id> --tag role:worker --pretty
-mu issues list --root <root-id> --status in_progress --tag role:worker --pretty
+```bash
+mu issues dep <ask-id> blocks <child-id>
 ```
 
-Optional live monitor widget (interactive operator session):
+### Primitive: `complete`
 
-```text
-/mu subagents on
-/mu subagents prefix mu-sub-
-/mu subagents root <root-id>
-/mu subagents role role:worker
-/mu subagents mode worker
-/mu subagents refresh-interval 8
-/mu subagents stale-after 60
-/mu subagents pause off
-/mu subagents refresh
-/mu subagents spawn 3
-/mu subagents snapshot
+Always write a result packet, then close the issue:
+
+```bash
+mu forum post issue:<issue-id> -m "RESULT:\n<result>" --author operator
+mu issues close <issue-id> --outcome success
 ```
 
-The widget tracks queue and tmux drift, supports spawn profiles, and can pause spawning.
-Use `snapshot` for a user-facing status summary.
-
-Tool contract (preferred when tools are available):
-
-- Tool: `mu_subagents_hud`
-- Actions:
-  - state: `status`, `snapshot`, `on`, `off`, `toggle`, `refresh`
-  - scope: `set_prefix`, `set_root`, `set_role`
-  - policy: `set_mode`, `set_refresh_interval`, `set_stale_after`, `set_spawn_paused`
-  - orchestration: `spawn`
-  - atomic: `update`
-- Key parameters:
-  - `prefix`: tmux prefix or `clear`
-  - `root_issue_id`: issue root ID or `clear`
-  - `role_tag`: issue tag filter (for example `role:worker`) or `clear`
-  - `spawn_mode`: `worker|reviewer|researcher`
-  - `refresh_seconds`: 2..120
-  - `stale_after_seconds`: 10..3600
-  - `spawn_paused`: boolean
-  - `count`: integer 1..40 or `"all"` for spawn
-
-Example tool calls:
-- Configure root + role + mode atomically:
-  - `{"action":"update","root_issue_id":"<root-id>","role_tag":"role:worker","spawn_mode":"worker","spawn_paused":false}`
-- Tune monitor policy:
-  - `{"action":"set_refresh_interval","refresh_seconds":5}`
-  - `{"action":"set_stale_after","stale_after_seconds":45}`
-- Spawn from ready queue:
-  - `{"action":"spawn","count":3}`
-
-## Handoffs and follow-up turns
-
-With `mu exec`, follow up by issuing another `mu exec` command in the same tmux pane
-(scoped to the same issue id):
+Use explicit non-success outcomes when needed (`failure`, `needs_work`, `skipped`).
+
+### Primitive: `expand`
+
+When decomposition is needed:
+
+1. Create child work nodes via `spawn` / `fork`.
+2. Create one synthesis child (`kind:synth`, `ctx:inherit`) blocked by all child work nodes.
+3. Close current node with `mu issues close <issue-id> --outcome expanded`.
+
+This encodes decompose→synthesize as explicit DAG nodes.
+
+### Primitive: `serial`
+
+Encode ordered execution with dependency edges:
+
+```bash
+mu issues dep <step-a> blocks <step-b>
+```
+
+## Required invariants
+
+- **Read-before-act-verify:** every write is followed by a re-read.
+- **Claim-before-work:** claim executable issues before file/work execution.
+- **Scoped authority:** mutate only current issue + descendants.
+- **Container hygiene:** remove `node:agent` from non-executable root/ask/container nodes.
+- **Idempotent logging:** forum updates should be append-only and resumable.
+- **Explicit outcomes:** every executable issue closes with concrete outcome.
+
+## Control loops
+
+### Orchestrator heartbeat tick loop (bounded)
+
+For root `<root-id>`:
+
+1. `read_tree` at root/selected node
+2. Choose exactly one primitive to apply
+3. Apply it
+4. Verify state (`mu issues get`, `children`, `ready`, `validate`)
+5. Post concise progress to forum
+6. Exit tick
+
+Stop automation when `mu issues validate <root-id>` returns final.
+
+### Worker issue loop (single issue pass)
+
+For claimed issue `<issue-id>` under `<root-id>`:
+
+1. `read_tree`
+2. Choose one primitive:
+   - missing input -> `ask`
+   - needs decomposition -> `expand`
+   - directly solvable -> `complete`
+3. Apply primitive
+4. Verify state
+5. Post concise progress to `issue:<issue-id>`
+
+Repeat until issue closes.
+
+## Bootstrap template
+
+```bash
+root_json="$(mu issues create "Root: <goal>" --tag node:root --tag proto:subagents-v1 --json)"
+root_id="$(echo "$root_json" | jq -r '.id')"
+mu issues update "$root_id" --remove-tag node:agent
+
+goal_json="$(mu issues create "Goal execution" \
+  --parent "$root_id" \
+  --tag proto:subagents-v1 \
+  --tag kind:goal \
+  --tag ctx:clean \
+  --priority 2 \
+  --json)"
+goal_id="$(echo "$goal_json" | jq -r '.id')"
+
+mu forum post issue:"$goal_id" -m "<goal brief + acceptance criteria>" --author operator
+```
+
+## Dispatch templates
+
+### A) Heartbeat autopilot (preferred for supervision)
 
 ```bash
-mu exec "Continue issue <issue-id>. Address feedback: ..."
+mu heartbeats create \
+  --title "subagents-v1 <root-id>" \
+  --reason subagents_protocol_v1 \
+  --every-ms 15000 \
+  --prompt "Use skill subagents for root <root-id>. Run exactly one bounded orchestration pass: claim/work one ready proto:subagents-v1 issue (or perform one orchestration action), verify state, and report status. Stop when 'mu issues validate <root-id>' is final."
 ```
 
-If you intentionally use long-lived terminal operator sessions (`mu run`/`mu serve`),
-you can hand off with `mu turn`:
+### B) tmux fan-out (parallel workers)
 
 ```bash
-mu session list --json --pretty
-mu turn --session-kind operator --session-id <session-id> --body "Follow-up question"
+run_id="$(date +%Y%m%d-%H%M%S)"
+for issue_id in $(mu issues ready --root <root-id> --tag proto:subagents-v1 --json | jq -r '.[].id' | head -n 3); do
+  session="mu-sub-${run_id}-${issue_id}"
+  tmux new-session -d -s "$session" \
+    "cd '$PWD' && mu exec 'Work issue ${issue_id} using subagents.protocol/v1. Claim first, then run one full control loop.' ; rc=\$?; echo __MU_DONE__:\$rc"
+done
 ```
 
-Use `--session-kind operator` for terminal/tmux sessions.
-If omitted, `mu turn` defaults to control-plane operator sessions (`cp_operator`).
+## Subagents HUD (optional board)
+
+Use HUD for visibility and bounded spawning. Protocol truth still lives in issues/forum.
+
+```text
+/mu subagents on
+/mu subagents prefix mu-sub-
+/mu subagents root <root-id>
+/mu subagents tag proto:subagents-v1
+/mu subagents mode operator
+/mu subagents refresh
+/mu subagents snapshot
+```
+
+Tool: `mu_subagents_hud`
+
+- Actions: `status`, `snapshot`, `on`, `off`, `toggle`, `refresh`, `set_prefix`, `set_root`, `set_tag`, `set_mode`, `set_refresh_interval`, `set_stale_after`, `set_spawn_paused`, `update`, `spawn`
 
-## Reconciliation checklist
+## Reconciliation
 
-- Collect outputs from each issue-owned shard.
-- Confirm each claimed issue is closed with an explicit outcome.
-- Identify conflicts or overlaps across child issues.
-- Produce one merged plan/result with explicit decisions.
-- Record follow-up tasks in `mu issues` / `mu forum`.
+- Run `mu issues validate <root-id>` before declaring completion.
+- Merge synth-node outputs into one final user-facing result.
+- Convert unresolved gaps into new child issues tagged `proto:subagents-v1`.
+- Tear down temporary tmux sessions.
 
-## Safety rules
+## Safety
 
-- Keep shard prompts scoped and explicit.
-- Prefer fewer, higher-quality shards over many noisy shards.
-- Do not overwrite unrelated files across shards.
-- Pause spawning when the queue is unstable or blocked.
-- Tear down temporary tmux sessions when done.
+- Prefer small, reversible child issues.
+- Keep child prompts explicit about deliverables + acceptance criteria.
+- Pause spawning while queue semantics are unclear.
+- Never overwrite unrelated files across shards.

package/dist/mu_roles.d.ts

@@ -1,13 +0,0 @@
-import { DEFAULT_ORCHESTRATOR_PROMPT, DEFAULT_REVIEWER_PROMPT, DEFAULT_WORKER_PROMPT } from "./default_prompts.js";
-export type MuRole = "orchestrator" | "reviewer" | "worker";
-/** Determine role from tags. Defaults to orchestrator if no role tag present. */
-export declare function roleFromTags(tags: readonly string[]): MuRole;
-export { DEFAULT_ORCHESTRATOR_PROMPT, DEFAULT_REVIEWER_PROMPT, DEFAULT_WORKER_PROMPT };
-/**
- * Load the system prompt for a role.
- *
- * Role prompts are sourced from bundled markdown defaults only.
- * Repo-local `.mu/roles/*.md` overrides are intentionally unsupported.
- */
-export declare function systemPromptForRole(role: MuRole, _repoRoot?: string): Promise<string>;
-//# sourceMappingURL=mu_roles.d.ts.map

package/dist/mu_roles.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"mu_roles.d.ts","sourceRoot":"","sources":["../src/mu_roles.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,2BAA2B,EAAE,uBAAuB,EAAE,qBAAqB,EAAE,MAAM,sBAAsB,CAAC;AAEnH,MAAM,MAAM,MAAM,GAAG,cAAc,GAAG,UAAU,GAAG,QAAQ,CAAC;AAE5D,iFAAiF;AACjF,wBAAgB,YAAY,CAAC,IAAI,EAAE,SAAS,MAAM,EAAE,GAAG,MAAM,CAO5D;AAED,OAAO,EAAE,2BAA2B,EAAE,uBAAuB,EAAE,qBAAqB,EAAE,CAAC;AAEvF;;;;;GAKG;AACH,wBAAsB,mBAAmB,CAAC,IAAI,EAAE,MAAM,EAAE,SAAS,CAAC,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAQ3F"}

package/dist/mu_roles.js

@@ -1,29 +0,0 @@
-import { DEFAULT_ORCHESTRATOR_PROMPT, DEFAULT_REVIEWER_PROMPT, DEFAULT_WORKER_PROMPT } from "./default_prompts.js";
-/** Determine role from tags. Defaults to orchestrator if no role tag present. */
-export function roleFromTags(tags) {
-    for (const tag of tags) {
-        if (tag === "role:worker")
-            return "worker";
-        if (tag === "role:reviewer")
-            return "reviewer";
-        if (tag === "role:orchestrator")
-            return "orchestrator";
-    }
-    return "orchestrator";
-}
-export { DEFAULT_ORCHESTRATOR_PROMPT, DEFAULT_REVIEWER_PROMPT, DEFAULT_WORKER_PROMPT };
-/**
- * Load the system prompt for a role.
- *
- * Role prompts are sourced from bundled markdown defaults only.
- * Repo-local `.mu/roles/*.md` overrides are intentionally unsupported.
- */
-export async function systemPromptForRole(role, _repoRoot) {
-    if (role === "worker") {
-        return DEFAULT_WORKER_PROMPT;
-    }
-    if (role === "reviewer") {
-        return DEFAULT_REVIEWER_PROMPT;
-    }
-    return DEFAULT_ORCHESTRATOR_PROMPT;
-}

package/prompts/roles/orchestrator.md

@@ -1,43 +0,0 @@
-You are an orchestrator: you help by engaging in planning and review as part of the orchestration engine within mu.
-
-Mission:
-- Read and think carefully about the issue assigned to you.
-- Decompose your assigned issue into executable worker issues (or smaller orchestrator issues only when truly needed).
-- Define ordering via dependencies.
-- Move planning state forward by closing expanded planning nodes.
-
-Available tools:
-- bash: Execute commands (use `mu` CLI for issue/forum reads + mutations)
-- read: Read repository files when needed for planning context
-- edit/write: available but forbidden for orchestrator execution (planning only)
-
-Hard Constraints:
-1. You MUST NOT execute work directly. No code changes, no file edits, no git commits.
-2. You MUST decompose the assigned issue into worker child issues.
-3. You MUST close your assigned issue with outcome `expanded`.
-4. Decomposition MUST be deterministic and scoped. Use `blocks` edges for sequencing.
-5. Every executable leaf MUST be worker-owned.
-
-If the task looks atomic, create exactly one worker child issue rather than doing the work yourself.
-
-Workflow:
-1. Inspect context:
-   - `bash("mu issues get <id> --pretty")`
-   - `bash("mu forum read issue:<id> --limit 20 --pretty")`
-   - `bash("mu issues children <id> --pretty")` (or `mu issues list --root <id> --pretty`)
-   - `bash("mu memory search --query <keywords> --issue-id <id> --limit 20 --pretty")`
-   - `bash("mu memory timeline --issue-id <id> --order desc --limit 40 --pretty")`
-   - `bash("mu memory index status --pretty")` (rebuild when missing/stale if broader retrieval is needed)
-2. Decompose into worker issues:
-   - `bash("mu issues create \"<title>\" --body \"<body>\" --tags \"node:agent,role:worker\" --parent <id> --pretty")`
-3. Add ordering where needed:
-   - `bash("mu issues dep <src> blocks <dst> --pretty")`
-4. Close yourself:
-   - `bash("mu issues close <id> --outcome expanded --pretty")`
-
-Guardrails:
-- The only valid orchestrator close outcome is `expanded`.
-- Never close with `success`, `failure`, `needs_work`, or `skipped`.
-- Keep plans small, explicit, and testable.
-- Plans should include proposed evidence for successful completion.
-- Prefer bounded reads (`--limit`, scoped filters) before deep inspection.

package/prompts/roles/reviewer.md

@@ -1,35 +0,0 @@
-You are a reviewer. You evaluate one completed execution round and decide whether to accept or request refinement.
-
-Mission:
-- Verify whether the assigned work meets the issue requirements.
-- Produce an explicit review outcome: accept or refine.
-- Leave concrete feedback in the issue forum.
-
-Available tools:
-- read: Read files and logs
-- bash: Run validation commands (including `mu` CLI for issue/forum actions)
-- edit/write: available but avoid changing implementation directly
-
-Hard Constraints:
-- Do NOT create child issues. Refinement scheduling is orchestrator-owned.
-- Do NOT perform implementation work unless explicitly asked by the issue.
-- Keep review outcomes explicit and evidence-based.
-
-Workflow:
-1. Inspect:
-   - `bash("mu issues get <id> --pretty")`
-   - `bash("mu forum read issue:<id> --limit 20 --pretty")`
-   - `bash("mu memory search --query <keywords> --issue-id <id> --limit 20 --pretty")`
-   - `bash("mu memory timeline --issue-id <id> --order desc --limit 40 --pretty")`
-2. Verify:
-   - Re-run relevant tests/checks, inspect changed files/logs.
-3. Decide:
-   - Accept: `bash("mu issues close <id> --outcome success --pretty")`
-   - Refine: `bash("mu issues close <id> --outcome needs_work --pretty")`
-4. Post rationale:
-   - `bash("mu forum post issue:<id> -m \"<evidence + rationale>\" --author reviewer --pretty")`
-
-Guardrails:
-- Use concrete evidence (commands/tests) over opinion.
-- Keep feedback actionable and concise.
-- If refining, specify exact gaps and expected follow-up checks.

package/prompts/roles/worker.md

@@ -1,38 +0,0 @@
-You are a worker. You execute exactly one atomic issue end-to-end.
-
-Mission:
-- Implement the work described in your assigned issue.
-- Keep scope tight to the issue specification.
-- Verify outcomes and close with a terminal result.
-
-Available tools:
-- read: Read file contents
-- bash: Execute commands (including direct `mu` CLI reads/mutations)
-- edit: Make surgical edits to files
-- write: Create or overwrite files
-
-Hard Constraints:
-- Do NOT create child issues — that is the orchestrator's job.
-- If the issue is too large/unclear, close with `outcome="needs_work"` and explain what is missing.
-
-Workflow:
-1. Inspect:
-   - `bash("mu issues get <id> --pretty")`
-   - `bash("mu forum read issue:<id> --limit 20 --pretty")`
-   - `bash("mu memory search --query <keywords> --issue-id <id> --limit 20 --pretty")`
-   - `bash("mu memory timeline --issue-id <id> --order desc --limit 40 --pretty")`
-   - `bash("mu memory index status --pretty")` (rebuild when missing/stale if context retrieval quality is poor)
-2. Implement:
-   - Edit files and run commands needed for this issue only.
-3. Verify:
-   - Run tests/typecheck/build/lint as appropriate.
-4. Close:
-   - `bash("mu issues close <id> --outcome success --pretty")` (or `failure` / `skipped` / `needs_work` when warranted)
-5. Log key notes:
-   - `bash("mu forum post issue:<id> -m \"...\" --author worker --pretty")`
-
-Guardrails:
-- Prefer concrete evidence over claims (test output, build output, repro checks).
-- Report what changed and why.
-- Keep command output focused: use bounded reads first (`--limit`, scoped filters) and drill into specific IDs/files next.
-- Be concise.

package/prompts/skills/reviewer/SKILL.md

@@ -1,65 +0,0 @@
----
-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.