Use when facing a batch of independent backlog tasks that can be planned and implemented in parallel. Use when the user asks to work on multiple tasks at once, execute a batch of tickets, or parallelize work across worktrees. Also use when the user says "run these in parallel", "batch these tasks", or "work on all of these".
Orchestrate batches of independent tasks by dispatching background subagents in isolated git worktrees. You are the orchestrator — you coordinate, compare, and review. All actual work (research, planning, implementation) happens in subagents.
Core principle: Never do the work yourself. Dispatch, monitor, compare, review.
Dependencies: field)When NOT to use:
digraph orchestration {
rankdir=TB;
node [shape=box];
identify [label="1. Identify parallel tasks\nfrom backlog"];
plan [label="2. Dispatch planning agents\n(background, isolated worktrees)"];
review_plans [label="3. User reviews plans"];
implement [label="4. Dispatch implementation agents\n(background)"];
compare [label="5. Compare style as agents complete"];
code_review [label="6. Dispatch code-review agent"];
fix [label="7. Fix review issues"];
merge [label="8. Merge + cleanup worktrees"];
identify -> plan -> review_plans -> implement -> compare -> code_review -> fix -> merge;
}
| Thing | Pattern | Example |
|---|---|---|
| Worktree branch | feat/task-{id} | feat/task-004 |
| Worktree directory | .claude/worktrees/feat-task-{id} | .claude/worktrees/feat-task-004 |
DoneDispatch one background agent per task with isolation: "worktree".
Each planning agent must:
docs/design/ thoroughlyAgent prompt template for planning:
You are planning TASK-{ID}: "{title}". Produce a detailed implementation
plan — do NOT write implementation code.
Research: read existing code patterns, migrations, design docs in docs/design/,
model types. Use context7 for library docs. Read CLAUDE.md.
Read the backlog skill to interface with the backlog. Write plan to the backlog ticket covering:
1. Context Summary 2. File Changes 3. Method Signatures
4. SQL Queries 5. Edge Cases 6. Testing Strategy 7. Open Questions
After all planning agents return:
After user approves plans, dispatch implementation agents.
Each implementation agent must:
go-htmx-fullstack)superpowers:test-driven-developmentsuperpowers:verification-before-completionAgent prompt template for implementation:
You are implementing TASK-{ID}: "{title}".
Setup:
1. Load the go-htmx-fullstack skill
2. Load superpowers:test-driven-development
3. Load superpowers:verification-before-completion
Read the plan from backlog (TASK-{ID}). Use context7 for library docs.
Read CLAUDE.md. Follow the plan. Write tests. Verify build + tests pass.
Commit with descriptive message. Update acceptance criteria in backlog.
Do NOT mark the task as complete.
As implementation agents complete one by one:
fmt.Errorf wrapping)This is critical because independent agents will make different style choices. Catch inconsistencies before they calcify.
After all agents complete, dispatch the superpowers:code-reviewer agent with:
git worktree remove + git branch -DAs the orchestrator, you should ONLY:
You should NEVER:
| Mistake | Fix |
|---|---|
| Doing research yourself while agents run | Trust the agents — read their output when done |
| Launching agents without detailed prompts | Include all context; agents start fresh with no history |
| Forgetting to compare styles across agents | Read each agent's code as it completes, build comparison table |
| Not specifying skill loading in agent prompts | Agents don't inherit your skills — tell them which to load |
| Skipping code review after parallel work | Independent agents WILL diverge — review catches this |
| Leaving worktrees behind | Always clean up: remove worktrees, delete branches |