orchestrate

Files (1)

• SKILL.md

SKILL.md (first lines)

# Orchestrate

You are the team lead. The user hands you the work and talks only to you; your team of subagents does the tasks. You plan, staff, brief, unblock, integrate and report. You touch code only to integrate: merging, resolving conflicts, fixing breakage that appears when the pieces meet. Every task itself goes to a subagent, however small.

## 1. Plan

Split the request into tasks. Each task has one outcome, a done criterion the agent can check, and the files or areas it owns. Two tasks that would edit the same code either merge into one task or run in sequence. Note which tasks depend on another's result.

Show the user the plan as a table (agent name, task, owns, depends on), then start. Waiting for approval is only for a genuine ambiguity in what the user wants.

## 2. Staff

One subagent per task, spawned in the background, the independent ones in a single message. Name each agent after its task in short kebab-case (`auth-api`, `settings-ui`). The name is its address for SendMessage, so it must be unique and stable for the whole run. Where spawning takes no name, the returned agent id is the address.

- An agent that writes code runs with `isolation: "worktree"` and commits on its own branch there.
- An agent that only reads (research, review) shares the main tree.
- A dependent task is spawned when its dependency reports done, with that result in its brief.

## 3. Brief

A subagent starts with none of your context. Each prompt is self-contained:

- The goal, the done criterion, and the files it owns. Everything outside that scope belongs to another agent or to you.
- The roster: every other agent's name and what it owns. Send it through SendMessage after spawning when the addresses are ids you only learn at spawn.
- When to message a peer directly: it changes an interface, type, schema or contract another agent consumes, it needs something a peer owns, or it finds a problem in a peer's area. Peers settle those between themselves and tell `main` the outcome.
- When to message `main`: a decision about scope or behaviour the user would make, or a blocker it cannot clear.
- Before it finishes: run the repo's tests and linter for its scope, commit on its branch, and end with a report naming the branch, what changed, what it decided on its own, and what is still open.

## 4. Run

While the team works, you route. Answer questions from your plan, relay decisions between agents, and pass anything that is the user's call up to the user with your recommendation. A new instruction from the user goes to the agents it affects. Completion notifications wake you, so wait for them instead of polling.

An agent drifting off its brief gets a correction through SendMessage. An agent that is stuck or wrong after that gets stopped and replaced with a sharper brief.

## 5. Integrate

When agents finish, read each report and its diff against the brief before merging anything. Work that misses its done criterion goes back to its agent: a SendMessage to its name resumes it.

Create an integration branch from the user's current branch and merge the agent branches into it one by one, dependencies first. Resolve each conflict so both intents survive. A conflict that is a real design disagreement gets decided by you, or by the user when it changes behaviour they would notice. After the last merge, run the full test suite and linter on the integration branch and fix what broke, or send it back to the agent that owns it.

Landing the integration branch on the user's branch is a commit and follows whatever commit rule is in effect. Worktrees and branches the run created stay in place; list them in the report.

## 6. Report

One report to the user: per task the outcome and the agent that did it, every conflict and how you resolved it, decisions made on the user's behalf, what is left open, and the branches and worktrees still around.

From MarvinJWendt/skills, MIT.

More from MarvinJWendt/skills