MissionsOne real mission, replayed end to end
One objective. Every system it touches.
A persistent local mission carries its plan, specialist work, browser and terminal activity, monitors, automations, and learned context beyond the session that started it.
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
- paula · platform
- systems in scope
- 6
- agents
- 4 + verifier
- approvals
- 1 gate · infra
Recorded mission · timestamps relative to acceptance6 phases below
The objective becomes a map.
Skyflo starts from the registered repositories and relevant local context needed to bound the objective before implementation begins.
- 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
canary + metrics
One plan. Approval before implementation.
The mission drafts one plan across the registered repositories and blocks until you approve the implementation 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
t+00:06approved by paula · scope pinned · execution unlocked
t+00:09Specialist agents. One boundary each.
Each specialist takes a bounded slice in an isolated worktree. The parent mission holds the objective, and a separate mutation-disabled reviewer can inspect the result.
- agents
- 4 specialists + 1 verifier
- 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"
Isolated worktrees. One parent mission.
Specialist changes remain in separate Git worktrees while the parent mission coordinates integration and keeps the approved objective intact.
- changes
- 4 bounded worktrees
- integration
- parent mission owns the seam
- execution
- linked Mac · registered repositories
An independent agent reviews the work.
The reviewer can read files, search, and report findings, but cannot edit files or run mutating capability operations.
- 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
The outcome outlives the mission.
Source-linked personal memory can be reviewed and accepted so a later mission can retrieve relevant context instead of starting cold.
- records
- scoped · cited · reviewable
- recall
- available when relevant
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?”
→ answered from this mission, six weeks later, in seconds.
replay complete·38 minutes wall clock·one objective, six systems, zero handoffs lost
Missions engineers actually run.
Cross-repository migrations, coordinated upgrades, security responses, and refactors — the work that used to need a spreadsheet, a war room, and one heroic staff engineer.
Move checkout workloads to ARM without interrupting traffic
6 systems coordinated · evidence on completion
Introduce tenant-level encryption across the platform
4 systems coordinated · evidence on completion
Upgrade the framework major version in every affected service
9 systems coordinated · evidence on completion
Patch a critical CVE everywhere it is actually reachable
12 systems coordinated · evidence on completion
Split the monolith's billing domain into its own service
5 systems coordinated · evidence on completion
Instrument p95 tracing across the request path
7 systems coordinated · evidence on completion
Questions
Missions, precisely.
The short version of how missions behave. For what Skyflo keeps between missions, see the knowledge system.
01What is a mission?+
A mission is the durable 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.
03Does Skyflo publish pull requests?+
No current product claim promises PR publication. Specialists work in isolated Git worktrees and integrate through the local harness.
04How is the work reviewed?+
A separate reviewer can inspect files and report findings, but cannot edit files or run mutating capability operations.
Your objective here
Run your first mission this week.
Skyflo Desktop is free with your own API keys or local models. Give it one real objective and watch it come back with evidence.
Missions run locally with the models you configure.