Parallel sprints with /conductor

Three agents. Three phases. One sprint. No daemon.

The idea

After the build phase finishes, /review, /qa, and /security can run at the same time. They read the same code, they produce independent artifacts, and they do not modify files during analysis. There is no reason to run them sequentially.

                    ┌─── Agent 1: /review ───┐
                    │                        │
/think → /nano → build ─── Agent 2: /qa ──────┼─→ /ship
                    │                        │
                    └─── Agent 3: /security ──┘

The sequential part (think, plan, build) runs in a single agent. The parallel part (review, qa, security) fans out to multiple agents. The final part (ship) waits for all three to finish, then aggregates.

How it works

/conductor coordinates through bin/sprint.sh, a shell script that manages phase state using the filesystem. No database, no message queue, no daemon process.

sprint.sh commands

sprint.sh start <sprint-id>      # initialize sprint state
sprint.sh claim <phase>          # claim a phase for this agent
sprint.sh complete <phase>       # mark phase done, save artifact
sprint.sh status                 # show all phases and their state
sprint.sh batch                  # auto-assign unclaimed phases

Phase states

Each phase moves through four states:

  • pending — not yet started
  • claimed — an agent is working on it
  • complete — artifact saved, ready for aggregation
  • failed — agent reported an error

Atomic locking

When an agent claims a phase, sprint.sh creates a lock directory at .nanostack/sprint/locks/<phase>/. The key insight: mkdir is atomic on POSIX systems. If two agents try to claim the same phase at the same instant, one succeeds and the other gets an error. No race conditions, no external lock service.

# Agent 1:
$ sprint.sh claim review
Claimed: review (agent: claude-code, pid: 42381)

# Agent 2 (simultaneous):
$ sprint.sh claim review
Error: review already claimed by claude-code (pid: 42381)

Auto-batching

If you have three terminal windows open, you do not need to manually assign phases. Run sprint.sh batch in each, and it claims the next unclaimed phase automatically:

# Terminal 1:
$ sprint.sh batch
Auto-claimed: review

# Terminal 2:
$ sprint.sh batch
Auto-claimed: qa

# Terminal 3:
$ sprint.sh batch
Auto-claimed: security

The assignment order follows the default priority: review, qa, security. If all parallel phases are claimed, batch returns a message saying there is nothing to claim.

Stale lock detection

If an agent crashes mid-phase, its lock directory stays on disk. sprint.sh status checks the PID recorded in the lock file. If the process is no longer running, the lock is marked stale and can be reclaimed:

$ sprint.sh status
review:   complete (artifact saved)
qa:       stale (pid 42399 not running, claimable)
security: complete (artifact saved)

$ sprint.sh claim qa
Reclaimed stale lock: qa

The stale detection checks every 30 seconds during active sprints. You can also force-reclaim with sprint.sh claim --force <phase>.

When /ship runs

/ship waits until all parallel phases are complete. It reads every artifact, resolves conflicts using the precedent framework, and produces the final sprint summary. If any phase is failed, /ship reports the failure and asks whether to ship without that phase's sign-off.

Previous← Secret scanningNextMulti-agent →