Claude Code by default is single-threaded in a human sense: one conversation, one working directory, one thing happening at a time. The moment you have three unrelated tasks — investigate a bug, add a feature, fix a flaky test — across one or more repos, you’re either running them sequentially in the same session (slow, and each one pollutes the others’ context) or manually juggling multiple terminal windows and manually tracking which one is stuck versus done. That’s a real bottleneck once you’re using an AI coding agent as more than a single-file autocomplete, and it’s exactly the same bottleneck an engineering team hits when they want several AI-assisted workstreams running at once without agents clobbering each other’s file changes or losing track of who’s blocked on what.

The specific workflow this project ports (Kun Chen’s FirstMate + Herdr) already solved this, but for Pi and Linux/WSL. I run Windows natively and use Claude Code as my daily driver, so I needed the same coordinator-plus-crew model rebuilt on a stack that doesn’t assume WSL and doesn’t assume a different underlying agent.

The end result is a single Claude Code chat — the “coordinator” — that you talk to in plain English, running inside Herdr, a terminal/window manager that keeps every pane alive in the background even if you close the laptop. You tell the coordinator things like “In doc-sanitizer, investigate why the encrypted index returns stale results” and “In cogniflow-ui, fix the flaky HTMX reload,” and it spins up separate Claude Code “crewmates,” each in its own disposable Treehouse git worktree, so they never edit the same files at once. Ctrl-b g pulls up an agent navigator showing every crewmate’s status (working / blocked / done) at a glance; when a crewmate finishes it reports back in the same conversation with a summary, a PR link, or a note that it’s ready for local review — you never dig through the worktree yourself.

Projects onboard in one of three delivery modes: local-only (nothing touches GitHub, safe default for anything new), direct-PR (pushes a branch and opens a real PR with no gate), or No Mistakes mode (a full review/test/document/lint pipeline has to pass before a PR counts as done — I ran this end to end against a disposable sandbox repo and watched it merge a real PR). For strict separation between projects, “secondmates” give a project its own dedicated coordinator and Herdr workspace instead of sharing the one primary chat — I run one for this tool itself and one for an investing project, each persisted independently and reachable with a jump key. I also built a small companion tool, herdr-jump, that’s effectively a quick-switcher: type or click a project name and it focuses that project’s terminal pane, creating one cd’d into the right directory if it doesn’t exist yet — bound to Ctrl-b j as a popup.

The other half of the build was making the whole setup actually survive a reboot: Herdr restores window/pane layout automatically but does not relaunch Claude Code inside each pane, so I wrote an auto-resume script (fires from a Startup-folder shortcut) that reissues claude –resume against every pane’s recorded session, plus a SessionStart hook that reasserts sidebar coloring/naming, which Herdr treats as live runtime state that gets wiped on every restart rather than persisted config.

The biggest lesson was how much of the “port to Windows” work was really debugging assumptions baked into a Linux-first toolchain: Cygwin’s ps has no -o custom-format support at all, so every process-ancestry check in the fleet-lock logic failed outright; a Bash-tool-spawned shell gets PPID=1 (reparented), so walking up the process tree to find the real harness process structurally can’t work the way it does on Linux — both needed a compatibility shim plus a Claude-specific PID fallback rather than a one-line fix. I also learned to distrust my own log-based conclusions: I initially read Herdr’s restart logs as proof that conversation reattachment was fully automatic, and only caught that it was actually the user manually typing claude –resume into each pane, because fast human action and automated relaunch produce identical log timestamps. Verifying against the user’s actual account, not just the log, was the only way to catch that.

The pattern here — one coordinator conversation dispatching isolated, trackable AI workers against real repos, gated by a review pipeline before anything merges — is the same shape a platform or DevOps team would want for scaling AI-assisted engineering past “one developer, one Claude session.” The delivery-mode ladder (local-only to prove it’s safe, direct-PR once trusted, full-gate No Mistakes for anything production-facing) is a reasonable default for how a team would want to introduce agent autonomy gradually rather than granting broad merge rights on day one. At team scale the open questions become: shared visibility across multiple people’s coordinators (right now the agent navigator is per-user), a real audit trail of what an agent changed and why beyond a PR description, and whether the isolation model (Treehouse worktrees) holds up when many people are dispatching agents against the same repos concurrently, not just one person running a personal fleet. Windows support specifically also matters more than it might seem — a lot of engineering orgs are not WSL-only, and tooling that assumes Linux paths and process semantics quietly excludes a chunk of a company’s actual developer machines.