Orchestrating agent teams with git worktrees
Four autonomous agents, one repository, zero stepped-on toes — the isolation and verification machinery that makes a TDD pipeline run unattended.
Running one coding agent is a parlor trick. Running four — a planner, an implementer, a spec reviewer, and a code reviewer — against the same repository without them clobbering each other is an engineering problem. superteam is the plugin I built to solve it for Claude Code.
Why worktrees, not branches
The naive approach gives every agent the same working directory and prays. The moment two agents edit overlapping files, you get a corrupted tree and a confused model. Git worktrees give each ticket its own checked-out copy of the repo, sharing one object store.
Isolation isn't a nice-to-have for multi-agent work — it's the thing that turns "interesting demo" into "I left it running overnight."
Each ticket gets a worktree. Agents working different tickets never see each other's uncommitted changes, and merges happen through the normal review gate rather than as a free-for-all.
Dependency-aware dispatch
Tasks aren't independent. A spec review can't start until implementation finishes; a code review can't start until the spec review approves. superteam models this as a dependency graph and only dispatches a task once its prerequisites report completion.
type Task = {
id: string;
kind: "plan" | "impl" | "spec-review" | "code-review";
dependsOn: string[];
status: "pending" | "in_progress" | "done";
};
function ready(tasks: Task[]): Task[] {
const done = new Set(tasks.filter((t) => t.status === "done").map((t) => t.id));
return tasks.filter(
(t) => t.status === "pending" && t.dependsOn.every((d) => done.has(d))
);
}The verification gate
The rule that keeps the pipeline honest: no task is "done" until its output is verified. An implementer doesn't get to mark its own work complete on vibes — the spec reviewer checks it against acceptance criteria, and the code reviewer checks it against the codebase's conventions. Only then does the dependency graph unlock downstream work.
This turns an autonomous loop from a confidence game into an auditable process. Across 12+ versioned releases, that gate is what made unattended runs trustworthy enough to ship from.