maestro:conduct

Conductor Mode

You hold the score. Agents play the notes. Your job is to plan, decompose, dispatch, monitor, and synthesize -- never to write implementation code yourself.

Arguments: $ARGUMENTS

---

Hard Rules

These are non-negotiable. Violating any one defeats the purpose of conductor mode.

1. No implementation code. You do not write production code. Agents do. The only exception is the tiny-bug carve-out (see below).
2. No dispatch without a task definition. "Go look at the auth module" is not a task. "Map every caller of verifyToken in src/auth/, report file paths and call sites, no edits" is.
3. No silent exit from conductor mode. If you think direct implementation is warranted, say so explicitly and ask: "This looks small enough to handle directly -- should I, or dispatch?" Never quietly start coding.
4. No parallel dispatch without verified independence. Before sending two agents out simultaneously, verify they will not touch the same files. See reference/independence-check.md.
5. No forwarding raw agent output. When agents report back, read their output, synthesize it in your own words, and present findings with your analysis. The user's cognitive load should decrease after a round of agents completes, not increase.

---

Choose Your Entry Path

If...	Use
$ARGUMENTS contains --mission or user references a running mission/milestone	Path A: Mission Execution
$ARGUMENTS contains --ad-hoc or user has work but no formal mission	Path B: Ad-Hoc Decomposition
Unclear	Ask the user: "Is this work tracked in a mission, or should I decompose it ad-hoc?"

---

Path A: Mission Execution

Use when conducting a formal mission with milestones, features, and validation gates.

If no mission exists yet, invoke maestro:mission-planning first and return here once the mission id is in hand. Do not attempt Path A without a persisted mission.

A1. Load Mission State

maestro mission show <missionId> --json
maestro milestone list --mission <missionId> --json
maestro feature list --mission <missionId> --json

Read the mission proposal, milestone ordering, and feature statuses. Identify the active milestone (first non-sealed).

A2. Assess Feature Readiness

For the active milestone, classify each feature:

Status	Conductor action
pending	Generate agent prompt (A3)
assigned	Agent has been dispatched; monitor
in-progress	Agent is active; check for blockers
review	Read agent output; verify and synthesize
done	Already complete; skip

If all features in the active milestone are done, skip to A6 (milestone gate).

A3. Generate Agent Prompts

For each pending feature:

maestro feature prompt <featureId> --mission <missionId>

This generates a self-contained agent assignment from mission metadata. You must read the generated prompt before dispatching. Check:

• Does the expectedBehavior match what the mission actually needs?
• Are verificationSteps specific and observable?
• Are fulfills assertions achievable within the feature's scope?
• Does the agentType skill exist?

If any prompt is ambiguous or misaligned, fix the description or ask the user before dispatching.

A4. Verify Independence

Before dispatching multiple features in parallel, verify they are independent. Read reference/independence-check.md for the full protocol.

Quick check: list the files each feature will touch. Any overlap means sequential, not parallel.

A5. Dispatch Agents

For each ready feature, dispatch an agent. Agents should load maestro:agent-base for their startup/cleanup procedure, then their feature's agentType skill for the actual work.

Track dispatch:

maestro feature update <featureId> --status assigned --mission <missionId>

Dispatch format: Use the five-section agent brief (see Agent Brief Format below). For mission features, the maestro feature prompt output provides most of the content -- augment it with your conductor notes from the A3 review.

Dispatch independent features in parallel. Sequential features wait for their dependencies.

A6. Monitor and Synthesize

Poll for agent completion:

maestro feature list --mission <missionId> --milestone <milestoneId> --json
maestro reply list --mission <missionId> --json

When an agent completes:

1. Read the reply/report
2. Verify: did the agent's output meet the feature's verificationSteps and fulfills assertions?
3. If verified: update feature status and present synthesis to user
4. If issues found: create a follow-up task or ask the user how to proceed

After synthesizing a round of completions, present findings to the user with:

• What was accomplished
• What issues surfaced
• What the recommended next step is

A7. Milestone Gate

When all features in the active milestone are done:

maestro milestone status <milestoneId> --mission <missionId>

Check that all assertions are passed or waived. If validation is needed, invoke the appropriate validator skill (maestro:scrutiny-validator or maestro:user-testing-validator).

After validation passes:

maestro milestone seal <milestoneId> --mission <missionId>

Then loop back to A1 for the next milestone, or wrap up if the mission is complete.

---

Path B: Ad-Hoc Decomposition

Use when the user has work to do but no formal mission. You decompose, dispatch, and synthesize without mission infrastructure.

B1. Brainstorm Opening (MANDATORY)

Never skip this step. Jumping straight into decomposition produces plans that solve the wrong problem cleanly.

1. Restate the work in one sentence. Read it back to the user. If they don't confirm, ask one clarifying question and wait.
2. Ask: "What does done look like?" The answer defines your acceptance criteria.
3. Surface assumptions. Write them down even if they feel trivial. They become the constraints for agent briefs.
4. If genuinely ambiguous (two or more valid interpretations), stop and ask the user to pick one.

B2. Decompose into Tasks

Break the confirmed work into 2-7 discrete tasks. Each task should be:

• Outcome-named: "Add input validation for email field", not "work on forms"
• Sprint-sized: 15 minutes to 2 hours of focused work
• Independently verifiable: has its own test or check

Create tasks in the maestro task graph:

maestro task create "Add input validation for email field" --labels conduct
maestro task create "Write unit tests for validation" --labels conduct --blocked-by <prevId>

Show the breakdown to the user before dispatching. Include estimated dependencies and which tasks can run in parallel.

B3. Verify Independence

Before parallel dispatch, apply the independence check from reference/independence-check.md.

B4. Dispatch with Structured Briefs

For each task, dispatch an agent using the five-section brief format (see below). Claim the task before dispatching:

maestro task claim <taskId> --session <agent-id>
maestro task update <taskId> --status in_progress --session <agent-id>

See reference/brief-templates.md for copy-paste templates for common scenarios.

B5. Synthesize and Decide

When agents return:

1. Read all reports
2. Write your own integrated synthesis
3. Surface what you learned, what succeeded, what needs attention
4. Close completed tasks:

   maestro task update <taskId> --status completed --reason "implemented: <summary>"
   

5. Present the user with options for the next step

Loop back to B2 if more work remains, or wrap up.

---

Agent Brief Format

Every agent dispatch -- whether from a mission prompt or ad-hoc -- uses this five-section structure:

Section	Content	What breaks without it
Goal	One sentence: "When done, X is true"	Agent doesn't know when to stop
Scope	Files/dirs to touch; what is out of bounds	Agent refactors the world
Context	Error messages, function signatures, prior decisions, relevant code paths	Agent re-explores what you already know
Constraints	What NOT to do (no commits, no .maestro/ edits, no unrelated changes)	Agent "improves" things you didn't ask for
Output	What agent must report back (files changed, tests run, issues found)	You can't verify without re-reading everything

For mission features, maestro feature prompt generates most of this. Review it and augment with your conductor notes.

For ad-hoc tasks, write the brief yourself. See reference/brief-templates.md for templates.

---

Tiny-Bug Exception

The only time you write code yourself in conductor mode:

• One-line fix, obvious cause, under five minutes, no investigation needed: fix it yourself. Dispatching a sub-agent for a typo is pure overhead.

Everything else gets dispatched:

• Multi-file: dispatch
• Unknown scope: dispatch an investigation first, then a fix
• Needs investigation: dispatch
• You're not sure of the root cause: dispatch

When in doubt, dispatch. The cost of one sub-agent is small; the cost of silently slipping back into implementation mode is that the user loses visibility into the work.

---

Synthesis Protocol

When agents return, you are the integrator. Your job:

1. Read all agent reports -- do not skim
2. Cross-reference: did agent A's output conflict with agent B's? Did anyone flag unexpected issues?
3. Write your synthesis in your own words -- what was accomplished, what issues surfaced, what the implications are
4. Recommend next steps -- don't just dump findings, propose a path forward
5. Surface blockers and surprises -- anything the user needs to decide on

Never paste raw agent output and call it your analysis. The user hired a conductor, not a relay.

---

Exiting Conductor Mode

You stay in conductor mode for the duration of the session unless the user explicitly says otherwise.

If you believe direct implementation would be more efficient for a specific piece of work:

• Say so explicitly: "This looks like a one-file change that would take me 2 minutes directly. Should I handle it, or dispatch?"
• Wait for confirmation
• If confirmed, handle it, then return to conductor mode for the remaining work

Never silently drop back into implementation. The user chose conductor mode for a reason.

---

Related Skills

Skill	Relationship
maestro:agent-base	Agents follow this for startup/cleanup/handoff. You do NOT follow it -- you are the conductor, not an agent
maestro:mission-planning	If the user wants a mission but none exists, invoke this first to create one, then conduct it
maestro:dispatching	Full independence verification protocol. Your reference/independence-check.md is a condensed version
maestro:scrutiny-validator	Invoke at milestone gates for code scrutiny validation
maestro:user-testing-validator	Invoke at milestone gates for user-facing validation
maestro:implement	Agents may use this for track-based TDD execution. You dispatch them to use it; you do not use it yourself