Use this when one repository has several features that can move in parallel but will eventually touch the same tree. The goal is real parallelism without a merge-day pile-up — and without you becoming the message router between teams. The core idea: one team per feature, each isolated in its own worktree, with only the supervisors meeting in a shared coordination channel.
This is the supervised development pattern repeated per feature, plus one coordination layer on top. The trick that makes it scale is isolation for the workers, a thin shared channel for the leads: workers never see each other’s noise, and cross-feature risk is surfaced by supervisors who summarize, not by every agent broadcasting every step.

​
Give each feature its own team and worktree

1

One group per feature

Create a group per feature — feature-a, feature-b, feature-c — each with its own agents and its own local channel for worker discussion.
2

One worktree per team

Put each team in its own git worktree so their working trees never overlap. Record the branch and worktree in the team channel’s first message so ownership is unambiguous.
3

A supervisor per feature

Each team runs the supervised pattern internally: a supervisor owns that feature’s board lane, gates, and lane assignments.

​
Coordinate through one channel of supervisors

Create a single coordination channel — for example repo-coordination — and add only the feature supervisors. This channel carries cross-feature signal, not worker chatter:
  • changed shared files and shared APIs,
  • migration ordering,
  • test debt and shared-suite breakage,
  • release blockers and merge order.
Keep workers out of the coordination channel. If every agent posts every detail there, it stops being a coordination channel and becomes noise. Supervisors summarize their team’s cross-feature impact; workers talk in their own feature channel.

​
Prevent the collisions before merge day

  • Shared modules get one owner. If two features need the same module, name one team its owner; the other consumes it and requests changes rather than editing it.
  • Shared APIs get a provider and a consumer. When two features touch the same interface, one team is the provider for that surface and the other the consumer, coordinated in the shared channel.
  • Integrate at planned windows, not at the end. Run scheduled integration passes — rebase or merge rehearsal, the shared test suite, conflict review, and an agreed merge order — so conflicts surface early and small.

​
What you get

  • Parallelism without a router. Workers move locally in isolated worktrees; supervisors coordinate globally in one channel; you are not the switchboard.
  • Conflicts found at sync points, not at final merge. Planned integration windows turn merge day from an event into a formality.

​
Next steps