MissionsIllustrative mission, phase by phase
A multi-repo mission, from objective to review.
An illustrative run through all six phases: discovery, plan approval, delegation, isolated implementation, independent review, and what the mission keeps afterwards.
One mission can coordinate AI coding agents across multiple repositories. Each specialist works in an isolated worktree, with terminal, browser, and automations attached to the same objective.
Mission manifest
rl-311 · per-tenant rate limiting
Objective
Introduce per-tenant rate limiting across the public API surface.
──no breaking change for existing clients
──limits configurable per plan tier
- initiated
- example operator
- registered checkouts
- 4
- agents
- 4 + verifier
- approvals
- 1 gate · infra
Illustrative product walkthrough, not measured customer evidence6 phases below
Read the workspace before touching it.
The mission opens read-only. It walks the registered checkouts, works out which of them the objective actually reaches, and pulls any memory from earlier missions that applies.
- mode
- read-only · no changes yet
- impact map
- observed before planning
- found
- registered checkouts · relevant memory
enforcement point
plan tiers · usage
usage dashboard
redis counters
build + deploy matrix
client retry behavior
One plan across four repositories.
The mission drafts a single plan covering every registered checkout, pins the interface all four will depend on, and blocks in plan mode until you approve the boundary.
- workstreams
- 4 · one per repository
- contract
- rate-limit headers · pinned v1
- gate
- plan approval → human decision
Pinned interface · v1
RateLimit-Limit · RateLimit-Remaining · RateLimit-Reset · 429 + Retry-After on exceed · limits.yaml per plan tier
approval requested · new redis cluster · est. $84/mo
plan proposedexample approval · scope pinned · execution unlocked
plan approvedOne specialist per repository.
Each specialist receives a packet naming its checkout, its slice of the objective, and the pinned contract, then works in its own git worktree. The parent mission keeps the objective, and a mutation-disabled reviewer is held back for the next phase.
- agents
- 4 specialists + 1 reviewer
- reviewer
- file.read · file.search · agent.report
- isolation
- one repo per agent · shared contract
Lead orchestrator
Holds the objective and the pinned contract
api-gateway
Repo agent 1
middleware + headers
model = "frontier"
billing-service
Repo agent 2
tier limits + events
model = "frontier"
platform-infra
Infra agent
redis · alerts · IAM
model = "fast"
web-console
Repo agent 3
usage UI
model = "fast"
Four worktrees that cannot collide.
Specialist changes stay in separate Git worktrees. The parent mission owns the seam between them, so integration is one decision rather than four repositories discovering each other late.
- changes
- 4 bounded worktrees
- integration
- parent mission owns the seam
- execution
- linked Mac · registered repositories
A reviewer with no write access.
The reviewer holds file.read, file.search, and agent.report, and runs with mutationAllowed set to false. It can read every worktree and report what it finds; it cannot change any of it.
- reviewer
- independent · mutation disabled
- tools
- file.read · file.search · agent.report
- profile
- read-only capability operations
file.read
reviewer can inspect the implementation
file.search
reviewer can trace relevant references
agent.report
findings return to the parent mission
mutationAllowed: false
reviewer cannot change the files
read-only capability operations
the role boundary is explicit
Three records, each with its source.
As the mission completes, Skyflo drafts what it taught. Records backed by the work's own evidence are kept; anything weaker waits for you. Each one stays linked to the mission and files that produced it, and a workflow this mission verified can become a Skill once another repository verifies it too.
- records
- scoped · cited · revertible
- recall
- retrieved when relevant
- compounds
- proven twice · becomes a Skill
Public API rate limits enforced at api-gateway via token bucket in Redis. Limits per plan tier live in platform-infra/limits.yaml.
429 responses must include Retry-After. SDK v2 clients retry automatically; v1 clients surface the error.
platform-infra owns the Redis cluster. billing-service owns plan-tier limit definitions.
❯recall“how do I raise limits for an enterprise tenant?”
→ retrieved from learned mission memory in a later session.
example complete·six product phases shown·one objective, four repositories, one review report
Other missions that span systems.
Cross-repository migrations, coordinated upgrades, security responses, and domain splits all need one approved objective to land consistently across several systems.
Move checkout workloads to ARM without interrupting traffic
6 systems · one approved plan
Introduce tenant-level encryption across the platform
4 systems · one approved plan
Upgrade the framework major version in every affected service
9 systems · one approved plan
Patch a critical CVE everywhere it is actually reachable
12 systems · one approved plan
Split the monolith's billing domain into its own service
5 systems · one approved plan
Instrument p95 tracing across the request path
7 systems · one approved plan
Questions
How missions behave.
Scope, isolation, and review. For what a mission keeps once it closes, see how Skyflo learns between missions.
01What is a mission?+
A mission is the persistent local unit that holds one objective, its plan, specialist work, execution history, and useful context.
02Can one mission span repositories?+
A workspace is an ordered set of registered Git checkouts; one mission may span them.
03Can other coding agents work across repositories?+
Yes. Several coding agents and orchestration tools can work across repositories. Skyflo's distinction is the mission record that keeps the approved plan, bounded specialists, execution evidence, independent review, and accepted memory together.
04Does Skyflo publish pull requests?+
No current product claim promises PR publication. Specialists work in isolated Git worktrees and integrate through the local mission.
05How is the work reviewed?+
A separate reviewer can inspect files and report findings, but cannot edit files or run mutating capability operations.
Your objective
Run one of these on your own repositories.
Skyflo Desktop is free with a signed-in coding agent or your own provider keys. Register the checkouts a change touches and give the mission the objective.
Missions run locally with the models you configure.