How I Built an Orchestrator-Worker System for Claude Code

Published: (January 10, 2026 at 11:58 AM EST)
2 min read
Source: Dev.to

Source: Dev.to

The Problem

When you’re working across multiple repos (backend, frontend, admin, infra), you need:

  • A coordinator that tracks progress but never touches code
  • Workers that focus on one task in isolation
  • Clean handoffs between sessions

Claude Copilot gave me the memory and task infrastructure. I needed to add the coordination layer.

What I Built

Orchestrator (coordinates, never executes)

  • Tracks status across all repos
  • Tells you which worker command to run
  • Updates sprint boards and invoices
  • Syncs with Notion

Workers (isolated execution)

  • Run in git worktrees (no branch‑switching conflicts)
  • Use git flow (feature/ branches)
  • Report progress via memory
  • Have strict start/done commands

Makefile‑based

No Python dependencies, just:

make worker-new REPO=backend TASK=fix-migration

Key Design Decisions

  1. Human‑in‑the‑loop
    Workers don’t spawn automatically. You decide when to start one, keeping you in control while still parallelizing work.

  2. Git flow native
    Every task is a feature branch, finished properly with git flow feature finish. No orphan branches, no merge chaos.

  3. Strict role boundaries
    The orchestrator literally cannot write code – it’s prompt‑enforced:

    ## CRITICAL: Your Role Boundaries
    
    **You COORDINATE. You do NOT EXECUTE.**
    
    ### You do NOT:
    - Write code or fix bugs (workers do this)
    - Work directly in sub‑repos (workers do this)
    - Create feature branches for tasks (workers do this)
  4. Worktree isolation
    Each worker runs in a separate git worktree. No branch switching, no stash juggling, no conflicts. Workers can run truly in parallel.

The Flow

┌─────────────────┐     ┌─────────────────┐
│   ORCHESTRATOR  │     │     WORKER      │
│   (main repo)   │     │   (worktree)    │
├─────────────────┤     ├─────────────────┤
│ • Track status  │────▶│ • feature/task  │
│ • Assign tasks  │     │ • Write code    │
│ • Update Notion │◀────│ • Report done   │
│ • Never code    │     │ • Cleanup       │
└─────────────────┘     └─────────────────┘

Try It

Everything is in my fork of Claude Copilot:

🔗

Key files

  • templates/Makefile.orchestrator – orchestration commands
  • .claude/commands/orchestrator.md – orchestrator behavior
  • .claude/commands/worker.md – worker behavior
  • docs/ORCHESTRATOR-WORKER-FLOWCHART.md – full system diagram

What’s Next

  • Better progress reporting between workers
  • Automatic conflict detection across worktrees
  • Tighter Notion integration

I’d love feedback from anyone solving similar multi‑session coordination problems. What’s your approach?

Built on top of Claude Copilot by Everyone Needs a Copilot

Back to Blog

Related posts

Read more »