Skip to content
Orbital
Menu
DocsExamplesReference
Workflow file
AttributesNode typesTemplate variablesContextError handlingHistory and threads
Interfaces
Command lineHTTP APIMCP tools
The app
SettingsAccounts and privacyModels and pricesShipped workflows

Shipped workflows

The eight workflows Orbital ships, what each needs, and their shared sub workflows

Pick one of the eight workflows Orbital ships from the new-run menu of any project. explain-repo only reads; the other seven deliver a pull request.

Workflow What it does Input Worktree and pull request
explain-repo Explains a repository. Optional goal No
implement-ticket Delivers one ticket. Ticket URL Yes
pursue-goal Delivers a goal written in plain words. Goal Yes
implement-epic Delivers an epic one ticket at a time. Ticket URL of the epic Yes, one per ticket
implement-epic-with-panel Delivers an epic with a panel of reviewers. Ticket URL of the epic Yes, one per ticket
improve-codebase Finds and delivers one improvement, then stops. Optional goal Yes, one per improvement
reduce-complexity Simplifies the function most worth simplifying. Optional goal Yes
port-project Ports an application to a new stack. Goal Yes, one per slice

The seven delivery workflows work in a worktree, deliver a pull request, and repair it until it merges or closes. They need a project on a Git repository with a GitHub remote. Each of them turns on auto-merge for its pull request, so GitHub merges it once your branch rules allow. To turn that off, take your own copy of each workflow you start and remove auto-merge from its subgraphs/pr-delivery.dot; Worktrees and delivery shows how.

To change a shipped workflow, open it on the Workflows page and edit it. Saving stores your own copy under the same name, which takes the shipped one over. Reverting deletes your copy. Workflows explains more.

explain-repo

Section titled “explain-repo”

Reads the project’s primary folder and answers with the repository’s purpose, who it is for, how it is built and how to run it. It is the first workflow to try: see your first run.

explain, then done.

  • Steps: one agent step, explain, in the Researcher role. It sets no tool access, so it runs the same on every harness. Its prompt tells it to only read and explain: no changed, created or deleted files, and only commands that read.
  • Where it works: your own checkout of the primary folder. It makes no worktree, branch or pull request.
  • Result: the step’s reply, the last message in the Session tab. The Context tab keeps it as response.explain.
  • Harness: Claude Code, Codex or OpenCode. On Codex the primary folder must be a Git repository.

implement-ticket

Section titled “implement-ticket”

Plans, implements and reviews one ticket, then delivers it to merge and completes the ticket. See implement a feature and open a pull request.

scope, then the deliver-ticket sub workflow.

  • Input: Ticket URL, ticket_url: a GitHub or Linear issue.
  • Steps: scope reads the ticket and writes the scope later steps work from. Then the deliver-ticket sub workflow makes a worktree, plans, implements, reviews, delivers and completes the ticket.

pursue-goal

Section titled “pursue-goal”

Implements a goal you describe in plain words, validates it, and loops back to implement until the goal is met, at most 20 times. Then it delivers the pull request to merge. See implement a feature and open a pull request.

create_worktree, implement, validate, delivery.

  • Input: the goal.
  • Ends: Succeeded when the pull request merges. Validation returns concrete findings to implementation until the change passes, without a separate checks or prerequisite gate.
  • Permissions: full, so every step runs without the harness’s permission check. See permissions.

implement-epic

Section titled “implement-epic”

Picks the epic’s next open leaf ticket that nothing blocks, delivers it the way implement-ticket does, and repeats until every leaf is done. Then it closes the epic. When every remaining ticket is blocked, it waits thirty minutes and looks again. See deliver an epic one ticket at a time.

select, ticket, and back to select; close_epic when none is left.

  • Input: Ticket URL, the epic’s address.

implement-epic-with-panel

Section titled “implement-epic-with-panel”

Works through an epic like implement-epic, but reviews each change once with eight reviewers in parallel, one per kind of problem, and allows at most two fix rounds.

select, implement, parallel review panel, triage, fix, second review, delivery.

  • Input: Ticket URL, the epic’s address.

improve-codebase

Section titled “improve-codebase”

Finds one worthwhile improvement, delivers it, and stops after cleanup. If discovery finds nothing worth doing, the run ends immediately without creating a worktree. See improve a codebase.

discover, implementation, delivery, cleanup, and complete; discovery also exits directly when nothing is found.

  • Input: an optional goal that points it somewhere. The default is “Find and deliver one worthwhile improvement at a time anywhere in the codebase.”

reduce-complexity

Section titled “reduce-complexity”

Measures complexity, picks the function most worth simplifying, and delivers the refactor as one pull request. It ends without a worktree when nothing is worth simplifying, and without a pull request when the refactor was not safe.

pick, create_worktree, refactor, delivery.

  • Input: an optional goal.

port-project

Section titled “port-project”

Ports an existing application to a new stack. It surveys the source into a parity ledger at docs/port/PARITY.md in the target repository, then ports and proves one ledger item per merged pull request, including database migrations, a data migration tested against the source’s schema, and a cutover guide. It ends only when an independent final check finds every item ported and proved.

create_worktree, survey, then slices until the final check.

  • Input: a goal naming the source repository, by path or address, and the target stack. For example, “Port ../legacy-shop to TypeScript on Node with Postgres”.
  • How it heals: a slice that fails review is repaired, then split, then replanned with a different design. When six rounds in a row prove nothing new, it replans the rest of the ledger. A pull request closed without merging is redone. Work that cleanup cannot remove is pushed to a salvage/ branch first.
  • Outside the repository: anything such as a credential or a paid service is ported behind an interface with an in-memory stand-in and a contract suite, and its live check goes into the cutover guide.
  • Permissions: full. See permissions.

Shared sub workflows

Section titled “Shared sub workflows”

The delivery workflows are built from three shared sub workflows. A workflow of your own can import them.

Sub workflow What it does
deliver-ticket Makes a worktree, runs implementation, then pr-delivery, completes the ticket after the merge, and removes the worktree when nothing would be lost.
implementation Plans, implements and reviews one piece of work. A rejected review revises the plan and the implementation until the review passes.
pr-delivery Publishes the pull request, turns on auto-merge, waits at “The pull request is waiting for review or merge”, and repairs conflicts, failing CI and requested changes until it merges or closes.

Steps that change code run in the Implementer role, and steps that review or validate run in the Reviewer role.

Section titled “Related”