/maestro-graph

name: maestro-graph
description: Drive a pre-known multi-agent path as a maestro graph - run it by name or from a file you just wrote, pull each agent node with graph next, spawn it as a sub-agent under its maestro-<profile> definition, hand the result back with graph result, repeat until the verdict. A sub-agent node reads or writes as its profile allows, and the chat running the graph reviews every diff a writing node leaves; a node whose result another seat must accept is opened as a pane instead. Author a new graph from the reference when no preset fits.
review-date: 2026-11-28

<!-- maestro-skill-version: dev -->

maestro-graph

Use when a task is a pre-known path with several agent steps: a review gate, a research sweep, a judge panel, a fix loop. The path is one markdown graph file; maestro holds the run, executes the deterministic nodes itself and hands you only the agent and human nodes to spawn. maestro never starts a model (Hub d78), so the loop below is yours on every harness. Design, diagnosis and the SLP seat protocol stay outside graphs.

Pick or write the graph

• `maestro graph list` shows every graph across the repo

(`<repo>/.maestro/graphs`), the room (`~/maestro/graphs`) and the shipped set; a nearer file shadows a farther one by name. `maestro graph show <name>` prints one.

• A shipped preset fits: run it by name. `review-gate` takes `range=<git

range>`, `tier=light|full`, `intent=<what the change is for>` and, on a re-run, `justified=<file:line reason per line>`; `fix-loop` takes `scope=<what to fix>` and `check=<command that must pass>` and drives a writing fixer for at most three rounds; `council` takes `brief=<neutral brief>` and `tier=lens|debate|debate-with-proof|high-risk` and runs the maestro-council protocol with you (the Lead) answering the draft and verdict nodes.

• Nothing fits: write a graph for the task from

[references/authoring.md](references/authoring.md) and run it with `--file <path>`. Keep a good one by copying the file into a graphs directory (Hub d100; there is no save verb).

The pull loop (executor subagent)

maestro graph run <name>|--file <path> [key=value ...] [--limit k=v] --json > run.json
loop:
  envelope = read run.json (or maestro graph next <run> --json > run.json)
  if envelope.done: stop; the verdict, LIMIT stop or failed node is in it
  for each node in envelope.nodes (all at once, they are independent):
    kind human  -> stop and ask the user the prompt; feed the answer back
    kind agent  -> spawn a sub-agent with the node's profile and brief
  for each returned sub-agent:
    maestro graph result <run> <ref> --file <path>|--text "<result>"
  maestro graph next <run> --json

• A sub-agent node reads or writes as its profile allows: review lenses

are read-only, `fixer` and `delegate` write. Review every diff a writing node leaves before the next node reads the tree. A node whose result another seat must accept is opened as a pane with `maestro work add --to <peer>` and its result handed back with `graph result` as before.

• `run` returns the first envelope, so the first `next` is implicit.
• Redirect every `--json` envelope to a file and read the fields you need

out of it (`jq`, or one `python3 -c` line); never let it land inline. An envelope carrying several node briefs and their schemas routinely passes a harness output cap, and a truncated envelope costs a second read of the same bytes before the loop can continue.

• Every node in `nodes` is ready now; spawn them in parallel. Nodes that

depend on one of them appear on a later `next`, as soon as their own inputs are in: only a `join` waits for a whole fan-out (Hub d82).

• `ref` is the node id, or `node@key` for one instance of a foreach.
• A node with a `schema` must return JSON of that shape. Write the

sub-agent's answer to a file and pass `--file`; maestro extracts the first JSON block from prose or a fence. `PARSE_FAILED` with `retry: true` means re-ask that sub-agent for JSON matching the schema carried in the error (two retries); the third failure marks the node failed and the run ends with `failed`.

• `stopped: "LIMIT"` ends the run at a structural limit (`nodes`, `loops`,

`fanout`, Hub d84) with `partial` state; rerun with `--limit <k>=<N>` when the cap, not the graph, was wrong.

• `GRAPH_UNTRUSTED` on a repo graph's function node: review the file the

error names, then run the `maestro graph trust` command it gives and `graph next` again. Home and shipped graphs never ask.

• `maestro trace <run>` is the journal: every node transition and round.

Spawning an agent node

The profile is a definition `maestro install` rendered for both harnesses (Hub d83): `~/.claude/agents/maestro-<profile>.md` and `~/.codex/agents/maestro-<profile>.toml`.

• Claude Code: the `Agent` tool with `subagent_type: "maestro-<profile>"`,

`model: "opus"` (graph nodes are judgment and writing roles), and the node's `brief` verbatim as the task. A profile whose `harness` is codex (challenger, verifier, auditor, reviewer-correctness-codex) opens as a Codex pane with `--profile maestro-<profile>` instead; the Agent tool rejects its model.

• Codex: `spawn_agent` with agent type `maestro-<profile>` and the node's

`brief` verbatim.

Send the `brief`, never the bare `prompt`: the brief is the prompt plus, when a schema is declared, one sentence naming the required keys and any optional keys, then the schema as a JSON block (Hub d843), so the agent answers in the declared shape instead of its harness habit. It already carries the run state the graph author placed in it. Add only what the harness needs to return the answer (for example, "write your JSON answer to <path>"). Never merge two nodes into one spawn and never run a function node's command yourself; maestro already did.

Executor team

`graph run` reports `executor` in every envelope (Hub d88): `subagent` from a plain session, `claude -p`, `