Most AI coding setups stall on coordination, not capability. This skill puts a lead agent in charge of breaking down goals, assigning parallel workers, and holding all output until you approve. You set the goal, answer blockers, merge the result. Setup runs under 20 minutes.
You open Claude Code. You type a task. The agent builds for a while, then stops to ask what to do next.
That is not a model problem. That is a coordination problem. You are doing the work a lead agent should be doing.
The multi-agent dev coordination skill restructures the whole setup. One lead agent reads your goal, breaks it into tasks, assigns each one to a worker running on its own branch, and escalates only what it genuinely cannot resolve alone. Every completed piece goes into a review queue. Nothing touches the main branch until you approve it. You stop being the coordinator and go back to being the decision-maker.
What This Solves
Development overhead rarely comes from bad code. It comes from questions: who is building which part, whether task B can start before task A finishes, whether an ambiguous requirement means everything stops.
A solo operator running three AI agents hits this just as hard as a team of five developers. The bottleneck is coordination, not the agents' ability to write code.
The architecture in one sentence: one lead agent orchestrates N worker agents, each on its own branch, with live output visibility and a merge gate you control.
Step One: Set the Goal Once
Your input is a single goal in natural language.
"Build a login page with email and password fields, error states, and a reset flow." That is the full input. Not a spec document, not a ticket breakdown, not a list of subtasks.
The lead agent reads it and builds everything else.
What makes a good goal: a feature, not a project. "Add rate limiting to the API endpoint" works. "Rebuild the auth layer" does not. It is too large to decompose in one pass. Break large projects into feature chunks and run the skill once per chunk.
The mistake that makes it fail: giving the skill two features framed as one. Workers end up with overlapping scope and conflict on the same files. Keep the goal tight enough to describe on one sticky note.
Done. The goal is set.
Step Two: The Lead Agent Plans and Assigns
Once the goal lands, the lead agent does three things before any worker touches a file.
First, it decomposes the goal into tasks. Each task has a clear deliverable, fits inside a single git worktree branch, and either has no dependency on other tasks or flags the dependency explicitly.
Second, it writes the full task list to a planning document. A flat Markdown file or Notion page works. You see the complete picture at any moment without asking for a status update.
Third, it spawns one worker per task, passing each worker the task spec and the path to its assigned worktree.
The planning document is load-bearing. It is the single source of truth for the entire run. If you pause work mid-flight, add a task, or hand the project off, that document has everything. Do not skip it.
Step Three: Workers Build in Isolated Branches
Each worker runs in its own git worktree: a separate branch with a clean copy of the codebase.
Workers build in parallel without conflicting on the same files. Three tasks, three workers, all running at the same time. A task that takes three hours does not block the other two.
Open any worker's terminal and watch every line of code it is writing. Not a summary, not a log file. Live output as it types. You do not need to watch constantly, but the option is always there.
| Agent | Worktree | Status |
|---|---|---|
| Worker A | feature/login-ui | Building |
| Worker B | feature/auth-api | Blocked — awaiting schema decision |
| Worker C | feature/reset-flow | Done — in review queue |
Workers signal two states: DONE or BLOCKED. DONE means the task is complete and in the review queue. BLOCKED means it hit something it cannot resolve without more information.
The mistake that makes it fail: task scope that overlaps. If two workers both think they own the same utility function, they build two versions. The lead agent's decomposition step prevents this, but only if your goal is clean enough to decompose clearly.
Step Four: Blockers Come to You, Not the Other Way Around
When a worker signals BLOCKED, the lead agent reads the blocker first.
If it can resolve it from the codebase, it does. No escalation, no interruption to you. The worker gets the answer and continues.
If it cannot resolve it without a human decision, it escalates to you. The format is fixed every time:
- The specific question — one sentence
- The two most likely options
- Which one the lead agent would pick and why
You answer in one line. The worker continues. Under two minutes for the full exchange.
Most blockers are resolvable from the codebase. The ones that are not tend to be ambiguous requirements or missing dependencies you would have needed to sort out anyway. The difference is timing: you handle them when the lead agent asks, not when you stumble on them yourself an hour later.
Step Five: Nothing Ships Without Your Sign-Off
When a worker completes its task, output goes into a review queue.
You see a diff, a short summary of what changed and why, and a decision: merge or request changes.
Diff looks clean, hit approve. Something is off, return it with a one-line note. The worker revises and re-submits.
The lead agent reviews the diff itself before forwarding it. Work it considers incorrect gets returned before it reaches you. You are the final gate, not the first one.
Nothing merges to the main branch until you approve it. That invariant does not change regardless of how many workers are running.
The SKILL.md Structure
This is the file that runs the coordination pattern. Install it in your project's .claude/commands/ folder and invoke it with:
Copy this.
/multi-agent-dev-coord "your goal here"
The file has four sections:
Goal intake. The lead agent reads the goal and breaks it into independent tasks. Each task needs a clear deliverable and clean scope. Dependencies get flagged, not assumed.
Worker spawn. One worker per task, each with its task spec and the worktree path. Workers report DONE or BLOCKED with a one-line reason.
Escalation rule. If a worker is BLOCKED and the lead cannot resolve it from the codebase, it escalates using the three-part format: specific question, two options, recommendation. No unformatted "I need help" messages.
Merge gate. Completed work goes into a review queue. The lead reviews the diff first. Nothing merges to main without operator sign-off.
Customize the sections in brackets for your project. The logic stays the same across projects; only the context changes.
What You Need
| Requirement | Notes |
|---|---|
| Claude Code with Agents feature | Multi-agent orchestration requires agent spawning |
| Git repository | Worktrees require a git repo — works on any existing project |
| The coordination SKILL.md | The orchestrator file, linked in the guide below |
| A planning document location | A Markdown file or Notion page for the task board |
No new accounts. No external APIs. Nothing paid. Everything runs inside your existing Claude Code setup.
Honest: What This Does Not Do
Goal quality matters. The lead agent decomposes what you give it. A vague goal produces vague tasks. Workers with overlapping scope conflict. Sharpen the goal before you run it.
You are still in the loop. This removes coordination overhead, not your involvement. You answer blockers and approve merges. A fully automated no-oversight pipeline is a different thing entirely. If that is what you want, this skill is one layer of it, not the whole stack.
Start with 2 workers. Your first run should have a two-worker goal with clean task separation. Get comfortable with the escalation flow and the merge approval before you run four or five agents in parallel. Complexity at scale compounds fast.
Context limits apply. Long-running tasks that require a worker to hold large amounts of context mid-session can stall. Keep task scope tight enough to complete in one session. If a task is too large for that, split it further before you run.
Your First Run
Pick one feature in a project you already have in git. Something decomposable into exactly two sub-tasks: a front-end piece and a back-end piece, for example.
Install the SKILL.md into .claude/commands/. Set up a planning Markdown file. Run the skill with your feature description.
Watch the lead agent decompose the goal, spawn two workers, and write the task board.
Only step in when something escalates. Approve the output when it is ready.
If you spent under three minutes on active management for a feature that would have taken two hours of back-and-forth, the coordination layer is working.
Pick one small feature. Run it today.