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 the publish step of its pr-delivery sub workflow; Worktrees and delivery shows how.

To change a shipped workflow, open it on the Workflows page and edit it. Saving edits it in place, and Reset to shipped brings the shipped version back. Workflows 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.

explain, then done.

Steps: one agent step, explain, with the researcher style. 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.

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 imported deliver-ticket 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.

create_worktree, implement, validate, delivery.

Input: the goal.
Frontend review: after reduce_drift, the decide step frontend_changes asks a decision model whether the change makes significant changes to the frontend. A no goes straight to validate. Otherwise review_frontend runs the app from the worktree, critiques and polishes what the change shows, then hands on to validate. With no decision model, or no confident answer, the frontend is reviewed.
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 styles.

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

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

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

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

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

Shared sub workflows

The delivery workflows are built from three shared sub workflows, each a workflow file that another workflow imports as a step. A workflow of your own can import them too; see Import.

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. Before it addresses new review feedback, the decide step `triage_feedback` asks a decision model whether the feedback is an actual code review or only automated or informational noise, such as a bot’s build, deploy, preview, coverage or CI status. Noise is recorded as handled and the run goes back to waiting; it is not judged again until new feedback arrives. With no decision model, or no confident answer, the run addresses the feedback.

Steps that change code use the implementer style, and steps that review or validate use the reviewer style. Styles and personas describes both.

Worktrees and delivery: how delivery, worktrees and auto-merge work in detail
Ticket to merge: the ticket delivery workflow explained step by step
Workflows: open, edit and revert a workflow on the Workflows page
Examples: real jobs done with the shipped workflows