> For the index of every page in Orbital's docs, read https://docs.beta.runorbital.dev/llms.txt.

# 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`](#explain-repo) | Explains a repository. | Optional goal | No |
| [`implement-ticket`](#implement-ticket) | Delivers one ticket. | Ticket URL | Yes |
| [`pursue-goal`](#pursue-goal) | Delivers a goal written in plain words. | Goal | Yes |
| [`implement-epic`](#implement-epic) | Delivers an epic one ticket at a time. | Ticket URL of the epic | Yes, one per ticket |
| [`implement-epic-with-panel`](#implement-epic-with-panel) | Delivers an epic with a panel of reviewers. | Ticket URL of the epic | Yes, one per ticket |
| [`improve-codebase`](#improve-codebase) | Finds and delivers one improvement, then stops. | Optional goal | Yes, one per improvement |
| [`reduce-complexity`](#reduce-complexity) | Simplifies the function most worth simplifying. | Optional goal | Yes |
| [`port-project`](#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](/projects/worktrees-and-delivery/#turn-auto-merge-off) 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](/workflows/#the-workflows-page) explains more.

## 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](/get-started/first-run/).

![explain, then done.](/shipped/explain-repo.svg?v=900c23c839)

- **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

Plans, implements and reviews one ticket, then delivers it to merge and completes the ticket. See [implement a feature and open a pull request](/examples/feature-pull-request/#deliver-a-ticket-with-implement-ticket).

![scope, then the deliver-ticket sub workflow.](/shipped/implement-ticket.svg?v=82fe3ab50a)

- **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](#shared-sub-workflows) sub workflow makes a worktree, plans, implements, reviews, delivers and completes the ticket.

## 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](/examples/feature-pull-request/#deliver-a-goal-with-pursue-goal).

![create_worktree, implement, validate, delivery.](/shipped/pursue-goal.svg?v=dc2465a951)

- **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](/roles/#permissions).

## 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](/examples/deliver-an-epic/).

![select, ticket, and back to select; close_epic when none is left.](/shipped/implement-epic.svg?v=6755d01c84)

- **Input:** **Ticket URL**, the epic's address.

## 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.](/shipped/implement-epic-with-panel.svg?v=6d0a9eabf9)

- **Input:** **Ticket URL**, the epic's address.

## 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](/examples/improve-a-codebase/).

![discover, implementation, delivery, cleanup, and complete; discovery also exits directly when nothing is found.](/shipped/improve-codebase.svg?v=fa58f0a81a)

- **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

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.](/shipped/reduce-complexity.svg?v=68f0751032)

- **Input:** an optional goal.

## 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.](/shipped/port-project.svg?v=2e6f7a7327)

- **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](/roles/#permissions).

## 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.

## Related

- [Worktrees and delivery](/projects/worktrees-and-delivery/): how delivery, worktrees and auto-merge work in detail
- [Ticket to merge](/examples/workflows/ticket/): the ticket delivery workflow explained step by step
- [Workflows](/workflows/): open, edit and revert a workflow on the **Workflows** page
- [Examples](/examples/feature-pull-request/): real jobs done with the shipped workflows