Skip to content

Your First Prompt

The core loop in Orbit is simple: you describe a change as a numbered prompt, it waits in a queue for your approval, your agent runs it, and the result is recorded in a completion log. Everything else — Apollo, Sandbox, Coordinator, multi-node — is a variation on this loop.

A prompt has a header line and a body. The header carries the project, a unique per-project number, and a one-line description:

[Orbit] #1024 — Add a copy-to-clipboard button to the Vault reveal row
complexity: low
depends_on: #1019
  • complexity: routes the prompt to a model tier. Use it on every prompt. Low is for routine tasks and minor fixes; Medium is for real logic changes and new features; High is for structural or security-critical work.
  • model: is an explicit override and is mutually exclusive with complexity: — if you set both, complexity wins, so pick one.
  • depends_on: holds the prompt as waiting until the prompt it names ships. Use a bare number with no annotation.

The body is the actual instruction, ideally with explicit failure conditions so the agent knows what “done” means.

Open the Pipeline panel and click New Prompt (or press Shift+N). Pick the project, paste or write the prompt, choose whether to run it Live or in a Sandbox, and queue it. The prompt claims its number at insert and lands in the queue as a card.

Nothing runs until you approve it. Each prompt card shows a pre-check: amber chips flag risks like a very large prompt, install commands, multi-part scope, or wide file coverage — without blocking you. Depending on your settings, a tier may also auto-review the prompt with a fast model, show a manual reminder, or run a deeper review before the Approve button.

When you are ready, approve the card. The prompt moves from pending to running.

A running prompt streams its output live. When the agent finishes, Orbit records an entry in that project’s COMPLETION_LOG.md — prompt number, description, commit hash, model, and notes — and a lightweight validation pass checks the commit diff for ghost ships or stray file changes, labelling the result Validated, Ghost Ship, Wrong Files, or Skipped.

That entry is the source of truth. A real ship has a commit that changed at least one real file; a completion-log line with no file change is a ghost ship, not a delivery.