Conductor

---
name: conductor
description: Drive the Harnu fleet through the `harnu` MCP verbs — see every session/worktree and create sessions, terminals and worktrees. Use when the operator asks you to orchestrate, manage or set up work across several Harnu sessions or folders — "spin up a session for X", "make a worktree and start a session there", "what is my fleet doing", "fan this out across worktrees", "act as the conductor". Only works inside Harnu with the Control server (MCP) enabled. Do NOT use for planning a delivery end to end (that is orchestrate-delivery) or for grading finished work (delivery-verifier).
---

# 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 verbs

Reads (transcripts and absolute paths come back redacted):

- **`get_fleet`** — the live fleet: folders + sessions with their task state. Start
  here, always, so you reason over real state instead of assumptions.
- **`get_session { sessionId }`** — one session's state, including `spawning` for a
  dispatch that has not materialized yet.
- **`list_worktrees { folder }`** — the git worktrees of a repo, with their lineage.
- **`memory_read` / `memory_query`** — the repo's project memory (`.harnu/memory/`).

Mutations. **They run immediately — no per-action confirm, no grant to obtain
first** — and every one is recorded in Harnu's audit log:

- **`create_worktree { folder, branch, base? }`** — a new git worktree on a new
  branch, provisioned through the repo's `WORKTREE.md` so it is born usable. With no
  `base` it forks from the remote default branch; pass `base` explicitly to stack one
  branch on another. It appears in the sidebar grouped under its repo.
- **`create_session { folder, kind?, prePrompt?, bootOverride? }`** — open a session
  in `folder`, adopting the folder first if Harnu has never seen it. `prePrompt` is
  the task it starts on: write it as the complete instruction for that session.
- **`spawn_terminal { folder }`** — a split shell terminal (for builds, git,
  scripts — no Claude).
- **`create_card` / `update_card` / `move_card` / `archive_card`** — the roadmap
  board. A card is born in `backlog`; you may move it between `backlog`, `ready` and
  `review`, never to `done`.
- **`submit_manifest`** — the dispatch door: name the Ready cards to dispatch, in
  drain order.
- **`open_file` / `notify`** — surface a report or a heads-up in the operator's UI.

## How it is gated — work with this, not around it

1. **Off by default at the server level.** If calls fail with `SERVER_DISABLED`, the
   operator has not enabled the Control server. Stop and tell them; do not retry.
2. **A blocked folder is absolute.** `FOLDER_NOT_ALLOWED` means the operator blocked
   that folder (and everything under it) from the folder's menu. No grant reaches
   into it. Tell the operator; they can unblock it from the same menu.
3. **Two verbs still face the human**: `plan_mission` (it mints a capability grant)
   and `delete_card` (irreversible — `archive_card` is the reversible sibling).
4. **If the operator turned on "Ask before agent actions"**, every mutating verb
   comes back as a confirm instead of running. That is the one situation where
   `plan_mission` pays off: call it FIRST for a fan-out, and a single approval buys
   the whole batch.
5. **Your children are sandboxed.** Sessions you create cannot themselves drive the
   MCP server — no recursive Conductor — and run with permission-bypass flags
   stripped. You are the only Conductor; plan accordingly.

## `create_session` is a slow, honest verb

It blocks until it can tell you the truth (up to ~60s) and only ACKs `ok: true` when
the session actually materialized — a real process AND a transcript on disk.

`ok: false` with `SPAWN_NOT_MATERIALIZED` means the spawn did not confirm inside that
window. The session is **not** killed and the folder is **not** freed: a spawn can
land minutes late. Adopt the `syntheticId` from the ACK and poll `get_session` —
`status: "spawning"` means it is still on its way. **Never retry `create_session`
into the same folder while it is unresolved**; the retry is refused with
`SESSION_ALREADY_IN_FLIGHT`, precisely to stop two processes landing in one working
tree.

## Playbook

- **Set up a task** → `create_worktree` if it needs isolation → `create_session` in
  that worktree with a precise `prePrompt` describing the goal, the constraints and
  the done criterion.
- **Fan out** → one `create_session` per worktree, each with the same prompt
  parameterized per branch. `create_session` is slow, so treat a fan-out as a
  sequence of slow calls, not fire-and-forget dispatches.
- **A scratch shell** (run a build, inspect git) → `spawn_terminal` in the worktree.
- **Report** → summarize the fleet from `get_fleet` in plain language. You cannot
  read raw transcripts, so describe state, not contents. Deliverable text belongs in
  a file you `open_file`, not pasted into the transcript.

## Honest limits

- You see **redacted** state — no absolute paths, no transcript bodies. Do not claim
  to know what a session "said"; describe its state.
- You **cannot** answer another session's permission prompt or send it input. If a
  session is blocked on input, tell the operator.
- There is no kill verb. Stopping a session is an operator click.