DEV Community

Mohamed Aly Amin
Mohamed Aly Amin

Posted on

How I Built an Orchestrator-Worker System for Claude Code

#claudecode #ai #devtools #opensource

Back in early January, I was wrestling with a problem: coordinating multiple Claude Code sessions across different repos without losing context or stepping on my own toes.

I'd been using Claude Copilot - a framework that adds persistent memory, specialized agents, and task management to Claude Code. It's a solid foundation, but I needed something it didn't have: multi-session coordination.

My solution was an orchestrator-worker pattern built on top of Claude Copilot. I pushed the first version on January 6th.

The Problem

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

  • A coordinator that tracks progress but doesn't touch 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
Enter fullscreen mode Exit fullscreen mode

Key Design Decisions

1. Human-in-the-loop

Workers don't spawn automatically. You decide when to start one. This keeps 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)
Enter fullscreen mode Exit fullscreen mode

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       │
└─────────────────┘     └─────────────────┘
Enter fullscreen mode Exit fullscreen mode

Try It

Everything is in my fork of Claude Copilot:

🔗 github.com/skylight74/claude-copilot

Key files:

  • templates/Makefile.orchestrator - The 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

Still iterating on:

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

Would 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

Top comments (0)