Use caseMulti-repository engineering

When one change has to land in four repositories.

A workspace is an ordered set of registered Git checkouts. One mission spans them, so the plan, the shared contract, and the review stay attached to each other.

How Skyflo handles a change that crosses repositories: registered Git checkouts, one approved plan, a specialist per repository in its own worktree, and independent review.

Workspace topology

rl-311 · per-tenant rate limiting · 4 registered checkouts

one objective
01api-gateway

enforce per-tenant limits at the edge

worktree mission/rl-311consumes rate-limit headers v1

02billing-service

expose plan tier on the tenant record

worktree mission/rl-311publishes rate-limit headers v1

03web-console

surface the limit and remaining quota

worktree mission/rl-311consumes rate-limit headers v1

04node-sdk

retry on 429 with the returned backoff

worktree mission/rl-311consumes rate-limit headers v1

one plan, approved once·4 isolated worktrees·reviewer cannot edit

One objective, four registered checkouts, one approved plan.

What separate sessions leave unowned.

Several agents can edit several repositories. The remaining problem is keeping one contract, landing order, approval boundary, and review record across them.

One agent per repository

  • Four capable sessions still need one owner for the objective they share.
  • The interface can be re-derived differently unless one contract is supplied to each session.
  • Decisions from an earlier session can disappear from the landing order.
  • Repository-level review does not automatically establish that the combined change agrees.

One mission across the workspace

  • One plan covers every registered checkout, and blocks until you approve it.
  • The shared contract is pinned in each specialist's packet, not rediscovered.
  • Each specialist works in its own git worktree, so the changes cannot collide.
  • A reviewer with no write access inspects the result against the same objective.

Start with the workspace definition.

All four mechanisms belong to one objective rather than four unrelated sessions.

A workspace is an ordered set of registered Git checkouts, and one mission may span them. That is the whole mechanism: no import step, no monorepo requirement. The mission plans against every checkout it was given.

Implementation does not begin until you approve the plan. Plan mode blocks the turn, so the boundary you agreed to is the boundary all four specialists inherit. None of them re-derives it.

Each coder specialist works in its own git worktree. Four agents editing four checkouts cannot collide, and the parent mission keeps the objective while they work.

A separate reviewer receives file.read, file.search, and agent.report only, with mutationAllowed set to false. It reports on the change; it structurally cannot make one.

Register the checkouts your next change touches.

Point Skyflo at the checkouts, write the objective once, and approve the plan before anything is edited.

Free. macOS 14+. Apple silicon and Intel.