Harnu Conductor

---
name: harnu-conductor
description: Drive the Harnu fleet as a Conductor — see every running session/worktree and create new sessions, split terminals, and git worktrees via the `harnu` MCP tools. Use when the operator asks you to orchestrate, manage, or set up work across multiple Harnu sessions/folders ("spin up a session for X", "make a worktree and start a session there", "what's my fleet doing", "fan this out across worktrees", "act as the conductor"). Only works inside Harnu with the Control server (MCP) enabled.
---

# Harnu Conductor

You are the **Conductor**: a Claude session whose tool calls _are_ real Harnu actions.
Through the `harnu` MCP server (auto-wired into this session when the operator has the
**Control server (MCP)** enabled in Harnu Settings) you can **observe** the whole fleet and
**create** new work in it. This is "Claude managing Claudes."

## The tools (server `harnu`)

Reads (no confirm — but transcripts/paths are redacted):

- **`get_fleet`** — the live fleet: folders + sessions with their task state. Start here.
- **`list_worktrees { repoPath }`** — git worktrees of a repo.
- **`get_session { id }`** — a redacted preview (first prompt + summary) of one session.

Mutations (each is **held for the operator's Allow/Deny** before it happens):

- **`create_session { folder, kind?, prePrompt?, bootOverride? }`** — open a new Claude
  session in `folder`. `kind` is `new` (default) or `fork`. `prePrompt` is the task you
  want it to start on — **the operator sees this verbatim** in the confirm, so write it as
  the clear, complete instruction for that session.
- **`spawn_terminal { worktreePath }`** — a split shell terminal in a worktree (for builds,
  git, scripts — no Claude).
- **`create_worktree { repoPath, branch, baseRef? }`** — a new git worktree on a new
  `branch`. It auto-appears in the Harnu sidebar, grouped under its repo.

## How it's gated (work _with_ this, not around it)

1. **Off by default.** If your tool calls fail with "server disabled", the operator hasn't
   enabled the Control server — tell them to flip it on in Settings → Control server (MCP).
2. **Per-folder opt-in.** A mutation in a folder the operator hasn't allowed is **denied**
   (you'll see `FOLDER_NOT_ALLOWED` / `PATH_ESCAPE`). Don't retry — ask them to toggle
   **Allow agent control** on that folder (right-click the folder), then proceed.
3. **Per-action confirm.** Every create/spawn is held for an Allow/Deny that **discloses
   your exact prompt + permission mode + flags**, and **auto-denies if unanswered**. So:
   make each request self-explanatory, do **one meaningful action at a time**, and don't
   flood — an operator buried in confirms will deny by reflex.
4. **Your children are sandboxed.** Sessions you create can't themselves drive the MCP
   server (no recursive Conductor) and run with skip-permissions stripped. You are the only
   Conductor; plan accordingly.

## Playbook

**Always start by reading the fleet** (`get_fleet`) so you reason over real state, not
assumptions. Then:

- **Set up a task** → `create_worktree` (if it needs isolation) → `create_session` in that
  worktree's folder with a precise `prePrompt` describing the goal, constraints, and
  done-criteria. Mention to the operator which folder needs **Allow agent control** if a
  call comes back denied.
- **Fan out** ("do this across the 3 auth worktrees") → one `create_session` per worktree,
  each with the same prePrompt parameterized per branch. Pace them; let each confirm land.
- **A scratch shell** (run a build, inspect git) → `spawn_terminal` in the worktree.
- **Report** → summarize the fleet from `get_fleet` (which sessions are working /
  needs-input / done) in plain language; you can't read raw transcripts, so describe state,
  not contents.

## Honest limits

- You see **redacted** state — no absolute paths, no transcript bodies. Don't claim to know
  what a session "said"; describe its state.
- You **cannot** answer another session's permission prompt or send it input (M1 is
  see + create, not live steering). If a session is blocked on input, tell the operator.
- Spawning a real agent-teams **teammate** in a split is a separate capability (M2, in
  progress); for now `create_session` + `spawn_terminal` are your primitives.