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
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
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.
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. Another agent has to arrive at the same Skill, or you keep it yourself, before anything can call it.
Everything Skyflo keeps is listed on the Memory page with its sources, and a Skill can be reverted in one action.
Your workspace
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.