Skip to content

ONE CHANGE.
EVERY REPO.

Describe the change once. A coordinator agent turns it into a spec with you, checks every plan against the others, then runs a planner → implementer → tester pipeline for each repo, package or part of an app, in parallel, each in its own git worktree.

GET STARTED VIEW ON GITHUB
v1.2out now: role sessions and local models →
npm create @openfleet-tools@latest

Run it in a new, empty folder. Version 1.2 · open source · MIT.

EXAMPLE RUN account-id · 1/6 done

“Rename user_id to account_id in the API, both SDKs and every client”

  • apiDONE: plan, implement and test complete
  • sdk-jsTEST: testing
  • sdk-pythonRETRY 1/3: tests failed, retrying
  • billingTEST: testing
  • web (3 parts)IMPLEMENT: implementing
  • mobileAFTER SDK-JS: plan agreed, waiting until sdk-js finishes
plans.consistent8 plans agree, gate open
contract.changedcontracts/account.json → 4 repos
assumptionsdk-python keeps user_id as a read-only alias

Six repos. One coordinator. All at once.

Every planner runs first, and no code is written until the plans agree. Then each child (a repo, package or part of an app) gets an implementer and a tester, side by side. Ordering holds: mobile waits for sdk-js. web’s three parts merge into one branch. A broken test gets a fresh implementer, and any call the spec didn’t cover is logged for you to confirm. Every step lands in events.jsonl.

WATCH THE WHOLE RUN, EVENT BY EVENT
EXAMPLE RUN · ACCOUNT-ID
4:28

LATEST EVENTS

    Mocked run: the timings are made up, but every event type is one OpenFleet really logs. Replay a real run with pnpm demo from a repo checkout, or see this run event by event.

    You answer questions once. Then it’s hands-off.

    Questions from the agents go to the coordinator, or to a repo coordinator for a repo split into parts. They answer from the spec, or decide and log an assumption for you to review.

    1. 1WITH YOU

      Grill

      The coordinator interviews you about the change, suggests repos from repos.json, splits a big app into parts if you want, and confirms build and test commands.

    2. 2WITH YOU

      Spec

      It writes spec.md: goal, repos and their parts, contracts, a shared approach, baselines, ordering, acceptance criteria and branches. One last question, “anything to change?”, and your answer starts the run.

    3. 3HANDS-OFF

      Plan, then agree

      Every planner runs at once, read-only. Before any code is written, all plans are checked against the spec’s shared approach and against each other. Then the plans-ready gate opens.

    4. 4HANDS-OFF

      Build, test, merge

      In dependency order: an optional baseline, then an implementer and a tester. A failing test gets up to 3 retries, then one guided attempt. A repo split into parts merges them into one branch and runs its full build and tests.

    5. 5YOUR REVIEW

      Finish

      Changes come back staged in each worktree for your review, or as draft PRs that link to each other, one per repo. The summary lists every assumption, failure and follow-up.

    Everything a change across many repos needs.

    A worktree and branch for every child.

    Each repo, monorepo package or part of an app gets its own git worktree and branch. Agents never share a working tree. Parts of one repo merge into a single branch, and one PR.

    main
    • apiopenfleet/account-id
    • sdk-jsopenfleet/account-id
    • sdk-pythonopenfleet/account-id
    • billingopenfleet/account-id
    • web/setupopenfleet/account-id--setup
    • web/appopenfleet/account-id--app
    • web/uiopenfleet/account-id--ui
    • mobileopenfleet/account-id

    Shared contracts keep repos in step.

    The coordinator writes shared fixtures, and every repo’s contract tests run against them. A contract change is broadcast to the repos it affects.

    contracts/ 
    {
  "seq": 7,
  "actor": "api/implementer",
  "type": "file.edited"
}

    Every action on the record.

    An append-only events.jsonl with patches. Secrets are redacted.

    Pick up where it stopped.

    A failed child doesn’t stop the run. State lives in state.json, so openfleet resume continues later.

    plans.consistent

    Plans agree before code.

    Every planner runs first. Their plans are checked against the spec’s shared approach and against each other, per repo and then across repos, before the plans-ready gate opens.

    .env.local

    Apps run side by side.

    Each child gets its own port range, so apps and end-to-end tests run in parallel without clashing. Git-ignored files like .env.local are copied into every worktree, never committed.

    Cloud plans. Local hands.

    Every child role runs as its own session, with its own model and server. Keep the coordinator, planners and testers on cloud models, and send the edits to a local model through Ollama, with no proxy. In step mode each plan step gets a fresh session, so a small context holds one step at a time, and a step the local model can’t finish goes to a cloud fallback.

    CLOUD LOCAL · ONE SESSION PER STEP

    Three commands to your first fleet.

    You need Node.js 22+, git and a signed-in GitHub Copilot CLI or Claude Code. The quick start covers your repos, what a run does, what it can touch and every command.

    READ THE QUICK START
    ~/my-fleet
    1. # 1. make a workspace
      mkdir my-fleet && cd my-fleet
    2. # 2. install OpenFleet into it
      npm create @openfleet-tools@latest
    3. # 3. describe the change
      npx openfleet new account-id "Rename user_id to account_id everywhere"

    Run npx openfleet inside my-fleet: outside it, npx would fetch an unrelated npm package that is also named openfleet. From anywhere else, use npx @openfleet-tools/cli.

    Extend any step of the run.

    An extension is a folder of instructions. It can run its own agent at one of six points in the run, add to what an agent is told, or add a command.

    SEE HOW EXTENSIONS WORK
    1. pre-spec
    2. post-plan
    3. plans-ready
    4. pre-implement
    5. post-test
    6. post-run

    Write one prompt.
    Run it across every repo

    A coordinated fleet of agents carries the change through every repo. You review the result when it’s done.

    GET STARTED VIEW ON GITHUB