Pilot CloudGet started

From label
to merged PR

Label a ticket. Pilot plans it, builds it in its own branch, proves it with your checks and opens the PR.

  1. Ticket with the pilot label
  2. 01

    Intake

    A labelled ticket enters the queue.

    Spec check

    The ticket needs a section header and at least 100 characters. A thin ticket gets a label that asks for more detail.

    Docs →

    Pickup

    Pilot watches your tracker for the pilot label and takes the ticket.

    Docs →

    One run per ticket

    Pilot records each ticket it takes, so no ticket runs twice.

    Docs →
  3. 02

    Plan

    Pilot sizes the work before it writes code.

    Size

    Each ticket gets one of five sizes: trivial, simple, medium, complex or epic.

    Docs →

    Model tier

    Small tickets go to a fast model. Larger tickets get a deeper planning pass.

    Docs →

    Epic split

    An epic becomes 3 to 5 sub-issues in order. The next one waits until the previous PR merges.

    Docs →
  4. 03

    Build

    Each ticket runs alone, with your project context.

    Own worktree

    Each ticket gets its own git worktree and branch. Parallel tickets do not collide.

    Docs →

    Project context

    Navigator loads your architecture notes, patterns and past decisions before the first edit.

    Docs →

    Stall watch

    A monitor warns, then pauses, then stops a run that makes no progress.

    Docs →
  5. 04

    Prove

    The work passes your checks before a PR exists.

    Quality gates

    Build, test, lint, coverage, security, typecheck or your own command.

    Docs →

    Evidence

    Commands from the acceptance checklist run in the worktree. The PR lists what passed and what is not verified.

    Docs →

    Self-review

    The agent reads its own diff against each acceptance criterion and each file the ticket names.

    Docs →

    A failed gate goes back to the agent with the error. Then the gates run again.

  6. 05

    Ship

    The PR goes through CI and your merge rules.

    Pull request

    The PR has a conventional title and a comment with duration, tokens and cost.

    Docs →

    CI watch

    Pilot finds the required checks on the repo and waits for each one.

    Docs →

    Review and merge

    Requested changes start a new run. The merge follows your environment rules.

    Docs →

    A red CI check gets a fix on the same branch. Then CI runs again.

  7. Merged PR

You stay in control

Labels show the state of each ticket. Your environment and approvals decide the merge.

On the ticketpilot→pilot-in-progress→pilot-done

Environments

  • devMerges when CI is green. No approval.
  • stageMerges when CI is green, then checks CI on main again.
  • prodWaits for your approval after CI, then tags a release.

Approvals

  • Before the runApprove the ticket before Pilot starts work.
  • Before the mergeApprove the PR after CI is green.
  • After a failureDecide to retry or stop a failed run.

Start

Run Pilot free in your terminal, or move the team to Pilot Cloud.

Terminal
Free

BSL 1.1 · your Claude key

View on GitHub
Pilot Cloud
USD 499

Per month, per organisation. No seats.

Open Pilot CloudWhat is included →