xiv ship
Everything xiv implement does, plus opening a PR and settling its CI status and human review comments.
xiv ship <issueId> [--base <branch>] [--tdd] [--skip-acceptance-review] [--max-iterations <n>]
# examples
xiv ship ENG-123
xiv ship ENG-123 --base develop --max-iterations 5issueId is a Linear issue key, for example ENG-123.
What it does
xiv ship launches the linear-to-pr Smithers workflow, pinned to the repo you run it from. It is the composition of two phases:
- Implement — the same plan → implement → validate → review loop as
xiv implement, on a dedicated branch, with the same local acceptance review gating each pass. - Publish and settle — push the branch, open a PR against
--base, then settle the PR: read its CI checks and human review comments, fix what they raise, and push again. This is the same settle behavior asxiv pr refine.
The settle phase acts only on the two signals GitHub alone can supply once a PR exists — CI status and comments from human reviewers. Code review itself already happened locally during the implement loop, so nothing waits on a review bot. xiv ship never merges the PR.
Flags
| Flag | Default | What it does |
|---|---|---|
--base <branch> | main | Base branch for the newly opened pull request. |
--tdd | off | Ask the implementation workflow to plan tests before production changes. |
--skip-acceptance-review | off | Skip the local acceptance-review step of the implement loop; validation (tests/lint/typecheck) still gates, and CI still runs once the PR is open. |
--max-iterations <n> | 3 | Implement → validate → review passes allowed before the run returns its last attempt. Clamped to 1–10. |
What to expect while it runs
A ship run is longer than an implement run: the implement loop, then a push, a PR, and at least one round of waiting on CI. Watch it with xiv ps / xiv logs / xiv ui (see Operations). The run reports a still-running build honestly rather than polling forever.
When it finishes you have an open PR with a real description — an agent reads the PR's own diff and writes Summary, Test Plan, and Known gaps — settled against whatever CI and human comments existed at the time. Merging is yours.
When to use it vs siblings
| You want | Use |
|---|---|
| Issue → review-ready PR, end to end | xiv ship |
| The work done locally, publication under your control | xiv implement |
| A branch that already exists pushed and opened as a PR | xiv pr refine --branch <name> |
| A whole feature (many issues) as stacked PRs | xiv stack |
If you ran xiv implement and later decide to publish, you don't need ship — xiv pr refine --branch <name> opens the PR from the existing branch and settles it, without re-running the implement loop.
Related
- Backing workflow: linear-to-pr
- The settle loop on its own: xiv pr refine / pr-review-loop
- The local review step: Review Model