Orchestration

A manager pattern for large tasks that break into a sequence of different kinds of work. The main agent stays a pure orchestrator: it decomposes the task, picks the topology that fits (a linear pipeline, a parallel fan-out, a dependency DAG, or an iterative loop), assigns each phase a tier, and runs phases as isolated sub-agents that exchange only file paths. It proves any expensive step cheaply before committing to it, validates each phase's output, surfaces progress as it goes, and stops at up to two points to let the user judge. It never does the phase work itself, and it never decides those points on the user's behalf.

Why the main agent never does phase work: a manager that also produces, runs, or scores inherits the producer's blind spots and loses the lean context it needs to sequence the whole run. Separating the orchestrator (decomposes, sequences, gates, reports) from the phase agents (each owns one phase in a clean context) keeps both honest — and keeps the orchestrator's context small enough to run a long task without drowning.

Why at most two user-judged stops, never more: the value is a long autonomous run the user can trust, not a babysat one. Most phases run on their own, and a run with no expensive step and no review halts zero times. But when those two judgments do arise — whether a cheap proof is good enough to commit the expensive step, and whether review findings are real — they are not the orchestrator's to make. Halting at every phase destroys the autonomy; folding either of these two into the orchestration makes it grade its own homework.

When to use

Only when the user explicitly invokes this skill or explicitly asks to run a task as a manager-driven sequence of sub-agent phases. Never auto-trigger on ordinary implementation requests or on task completion.

Use this when the task decomposes into heterogeneous phases — different kinds of work (investigate, produce, run, evaluate, report), in whatever topology fits. If the task is a single artifact that needs to be built and then reviewed, delegated-review-loop is the right tool. If it is a single answer that needs blind verification, iterative-self-review is the right tool. This skill is the backbone for everything larger and more heterogeneous than those.

Roles