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

# Improve a codebase

> Deliver small improvements one at a time, or one focused refactor, without a ticket

In this example you have Orbital improve a codebase without a ticket. Start the shipped `improve-codebase` workflow for one worthwhile improvement, or `reduce-complexity` for one focused refactor.

About five minutes to start. Both workflows stop after one improvement, or immediately when nothing worthwhile is found.

![improve-codebase: discover a candidate, implement and deliver it, then stop; exit immediately when there is nothing to do.](/shipped/improve-codebase.svg?v=fa58f0a81a)

## Before you start

:::caution
Both workflows turn on auto-merge. Where your branch rules require no review, each pull request merges as soon as its required checks pass. See [turn auto-merge off](/projects/worktrees-and-delivery/#turn-auto-merge-off).
:::

## 1. Choose a workflow

| Use | When |
| --- | --- |
| `improve-codebase` | You want one worthwhile improvement supported by evidence. |
| `reduce-complexity` | You want one refactor of the most complex code. |

## 2. Start the run

Follow the part for the workflow you chose.

### Run improve-codebase

1. Choose **New task**, pick the project and choose `improve-codebase`.

![The Start page asking what to do in a project, with a goal box, a harness picker, a workflow picker and a Chat or Workflow switch.](/screenshots/start-page.webp?v=0428f5d705)

*Choose the workflow, then point it somewhere in the goal box.*

2. Point it somewhere, or leave the default goal, "Find and deliver one worthwhile improvement anywhere in the codebase." To narrow it, write your own, such as `Improve test coverage of the billing module`.

3. Choose **Start run**.

The run finds one worthwhile improvement, delivers it as a merged pull request, and stops after cleanup:

| Step | What it does |
| --- | --- |
| **discover** | Looks for one worthwhile improvement and says why. |
| Deliver | If it finds one, the run makes a worktree, implements the improvement with a review loop, and delivers the pull request to merge. |
| Clean up | The run cleans up and ends. |
| No candidate | If it finds nothing worth doing, the run ends immediately without creating a worktree. |

### Run reduce-complexity

1. Choose **New task**, pick the project and choose `reduce-complexity`.

2. Optionally write a goal, such as `Only look at the src/api folder`.

3. Choose **Start run**.

![reduce-complexity: pick a target, refactor it in a worktree, deliver it.](/shipped/reduce-complexity.svg?v=68f0751032)

The pick step measures complexity and picks the function most worth simplifying. The run then refactors it in a worktree, delivers one pull request and stops.

## What you get

`improve-codebase` delivers at most one improvement per run. When discovery finds nothing worthwhile, it succeeds without creating a worktree or pull request.

`reduce-complexity` leaves one pull request with the refactor, except in two cases:

| Outcome | When |
| --- | --- |
| Succeeded, without a worktree | Nothing is worth simplifying. |
| Failed, without a pull request | The refactor was not safe. |

## Run it on a schedule

With the Triggers feature on, the ready-made rule "Improve the codebase every weekday morning" starts a run at 9:00 on weekdays. Its goal is "Find and make one small improvement to the codebase". Choose `improve-codebase`, `reduce-complexity` or your own workflow for it. Each scheduled run of `improve-codebase` considers one improvement and ends. See [triggers](/triggers/).

![The New rule dialog set to a schedule of every weekday at 09:00, with the next run times listed.](/screenshots/trigger-rule-schedule.webp?v=4af59dea16)

*A schedule rule lists its next runs before you save it.*

## Related

- [Shipped workflows](/reference/shipped-workflows/): every step of `improve-codebase` and `reduce-complexity`
- [Worktrees and delivery](/projects/worktrees-and-delivery/): how each improvement reaches a merged pull request
- [Make a trigger rule](/triggers/make-a-rule/): start runs on a schedule