When one change has to land in four repositories.
One mission spans your registered Git checkouts, so the plan, the shared contract and the review stay together.
How Skyflo handles a change that crosses repositories: registered Git checkouts, one mission, a specialist per repository in its own worktree, and an independent review in Orchestrate.
Workspace topology
rl-311 · per-tenant rate limiting · 4 registered checkouts
enforce per-tenant limits at the edge
worktree mission/rl-311consumes rate-limit headers v1
expose plan tier on the tenant record
worktree mission/rl-311publishes rate-limit headers v1
surface the limit and remaining quota
worktree mission/rl-311consumes rate-limit headers v1
retry on 429 with the returned backoff
worktree mission/rl-311consumes rate-limit headers v1
Illustrative example: one goal, four registered checkouts, one 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. Choose Plan mode and it waits for your approval first.
- With Orchestrate, the shared contract is pinned in each specialist's packet, not rediscovered.
- Each specialist works in its own git worktree, so its edits stay apart from the others while the work runs.
- A reviewer with no write access can check the combined result against the same goal.
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, up to eight, 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.
When you want to approve the plan before anything is edited, choose Plan mode. It holds the turn until you approve, so the boundary you agreed to is the boundary every specialist inherits. In Auto, work starts straight away under the mission's access mode.
In Orchestrate , each coder specialist works in its own git worktree, on Codex, Claude Code, Cursor Agent, or Skyflo's own agent. Their edits stay apart while they work, the lead keeps the goal, and bringing the four changes together is still a step you review.
A separate reviewer can read, search, ask and report, and cannot edit a file. Orchestrate adds one by strategy and risk. It reports on the change; it cannot make one.
The second repository is where Skyflo starts to compound.
Each mission leaves behind what it learned about the checkouts it touched. When a later mission in another repository verifies the same workflow, Skyflo can turn it into a Skill.
A convention you state in one mission, such as the checks to run before a commit, is kept for that repository once the work shows it ran. The next mission there starts with it instead of asking again.
One repository running its gate is that repository's habit. Two repositories verifying the same commands is a reusable workflow, so that is when Skyflo proposes a Skill. An independent agent has to arrive at the same Skill, or you approve it yourself, before anything can call it.
Everything Skyflo keeps is listed on the Memory page with its sources. Reverting a Skill stops later missions from using it; it does not undo work already done.
Register the checkouts your next change touches.
Add the checkouts, write the goal once, and choose Plan mode if you want to approve the plan before anything is edited.
Start free. macOS 14+, Apple silicon and Intel. Agent subscriptions and model keys you bring are billed by their providers.