# Ship it & pull requests

> Publish a thread with Ship it, follow pull-request checks and fixes in chat, and decide when green changes merge.

**Ship it** is the publish action for a thread, not a way to save a checkpoint. Work is committed to the thread's own branch at the end of each turn; you can inspect or [rewind](https://darting.dev/docs/checkpoints-and-rewind/) it before publishing. When a GitHub repository is connected, Ship it brings the branch up to date, pushes the work, opens a pull request, and follows that PR through checks and merge. One thread ships one PR. After it lands, new work belongs in a [fork or follow-up thread](https://darting.dev/docs/forks-and-follow-ups/).

## The button and the offer

The composer shows the publish control when there is work to ship. Once a turn has changed files, a **Ready to ship** offer also appears inline at the end of the transcript. It shows what changed and where the work is going; clicking it starts a ship card *in the conversation* at that point, where progress remains visible. The composer control and the card describe the same ship, rather than starting two different workflows.

Still working? Click **Ship when done** to queue the action. It waits for the agent and queued messages to finish; you can cancel the queued ship. Once a PR is open, clicking the shipping control pauses auto-merge without closing the PR, and clicking the paused control resumes it. You can also arm **Auto-merge** from the thread's Ship options. A draft PR must be marked ready before it can proceed. If your project tracks a separate production release, the control may say **Save** rather than promising that a PR merge immediately deploys it.

Knowledgebase entries, project rules, and plan updates written by the thread can stay **pending** alongside its code. Ship it carries them with the thread; they take effect when its PR merges, so project memory doesn't describe code that hasn't landed yet. If there are only pending document updates and no changed code, the offer can publish them without making a pull request. [Collections & history](https://darting.dev/docs/collections-and-history/) explains the pending state.

## Follow the PR in chat

The transcript reports shipping as short stage events: syncing with the default branch, opening the PR, CI running or passing, a failed check, merge, and — for a tracked deployment — production going live. Expand an event to inspect its detail. The ship card remains where you clicked and updates as the PR moves; the thread's status stays visible even when the agent is no longer typing.

On a red CI run, the agent receives the failed job names and log output in a **fix-only turn**. It makes a narrow correction, verifies it locally, and the turn-end commit is pushed to the open PR so GitHub runs checks again. Fix-only means no unrelated refactors, feature changes, or weakening tests to make a check pass. A failure that calls for a larger design decision is handed back to you rather than guessed through. Environmental problems such as a runner or third-party outage are investigated as such rather than disguised as code changes. You can use **Fix CI** on a failed PR when the automatic work has stopped.

```text
Ship it → sync branch → open PR → CI → ready to merge
                                  ↳ red → fix-only turn → push → CI again
```

## Merge only when you choose

Green checks make the PR ready; they do not force an unarmed PR into `main`. Turn on **Auto-merge** if you want it to land once checks and review allow it, or leave it paused until you are ready. Armed PRs go through the [merge queue](https://darting.dev/docs/merge-queue/), where overlapping changes wait their turn. If the default branch moved, the platform merges it into the thread branch before publishing or merging; conflicts are resolved as a turn of that thread rather than dropped. See [update from main](https://darting.dev/docs/update-from-main/).

For a project without a repository, the first ship can create one and save the thread's work. If your account is set to ship new repositories to GitHub and access is missing, **Connect GitHub** appears first; completing that connection creates the GitHub repository and saves the thread's branch there. Then **Ship it** opens the PR. When that PR merges, the thread closes with its published outcome. By default, a new repository is instead stored by darting: Ship it creates the repository and lands the thread on `main` as one commit, **without a GitHub PR or CI**. You can later move that repository to GitHub from project settings for the PR workflow. See [GitHub & authentication](https://darting.dev/docs/github-and-auth/).