Ways of working

Two paths, one pipeline

A mission is a mission. Across planner, builder, CI, reviewer, preview deploy and QA, the stages, the retry behaviour, the verdicts and the cost accounting are identical whichever way the work arrived.

What differs is where it starts and where it talks to you. That tends to split along who is handing the work over.

Neither is a lesser version of the other. They are two front doors into the same building.

Ticket to PR

Someone files an issue describing what they want, with acceptance criteria, and mentions @SHIP on it. That is the whole interface.

The mission reports back where the issue already lives, with a running commentary as it plans, builds, reviews and tests, and a pull request that closes the issue when it merges. Commenting on the issue is the permission, so nobody involved needs a SHIP login, a token, or anything installed.

Steering it is the same gesture. Reply on the ticket with what you want changed and the agents pick it up on the open pull request. Asking for a change to something a specific stage produced re-runs that stage rather than starting over. The controls are @SHIP pause, @SHIP resume and @SHIP stop, and the console has the same three as buttons.

Supported trackers are Linear and GitHub Issues. On GitHub the trigger is an @SHIP comment from someone with write access to the repository.

Agent to PR

You are in your editor with a coding agent and you have just produced something worth handing over, either a spec or a finished branch. There is no ticket, and for this kind of work there usually should not be one.

# You wrote the plan; SHIP skips its own planning and builds from it
ship delegate plan --title "Rate-limit the search endpoint" --file docs/plan.md

# You wrote the code; SHIP reviews it, tests it and drives it to merge
ship delegate pr

The hand-off creates the mission. With no tracker behind it the platform mints the id itself, something like M-3f9a2c1b04, and the console mission page is its home. That id is deliberately not shaped like a ticket reference, so nobody goes hunting for an issue that was never filed.

Your agent can do all of this for you. Running set up https://letsship.ai/SKILL.md teaches it when to delegate, which command fits, and how to report back. See Getting started.

Steering it is ship instruct:

ship instruct M-3f9a2c1b04 -m "Keep the current Node range, override nopt instead"
ship instruct M-3f9a2c1b04 --file review-notes.md
ship instruct M-3f9a2c1b04 -m "FYI staging is down until 14:00" --note

Use it rather than restarting. A restart re-evaluates the pull request against results it already has, correctly finds nothing changed, and does nothing, so it looks like it worked while the feedback goes nowhere. An instruction is the channel that carries new information, and --note leaves context for whatever runs next without starting any work.

What this path gets you that the ticket does not is per-mission control. --harness and --model pin how one mission runs without touching the project's configuration, and --prompt-file gives one role extra instructions for one mission, such as a security pass over this branch. Prefer --prompt-mode extend when you are adding a concern, so the repository's own conventions for that role survive.

Running both

A project does not choose. One with a tracker still accepts CLI hand-offs, and the two kinds of mission sit on the same board, write the same logs, produce the same verdicts and roll into the same cost reporting.

The paths also cross. ship instruct SHIP-412 steers a mission that started from a ticket, which is useful when the reviewer has raised something and you would rather answer from the terminal you are already in than write a comment. Everything either path can do is on the API too, so a bot or an internal tool is a third caller of the same surface rather than a special case.

A shape that works well in practice:

• Feature and bug work arrives as tickets, because the people asking for it already work there and the ticket is where the decision trail belongs.
• Refactors, upgrades, chores and anything a developer is already mid-thought about goes over from the terminal, because filing a ticket to describe work you have already specified is pure overhead.
• Both land as pull requests in the same repository, reviewed and tested the same way.

Choosing a project's tracker

The project's tracker is set when you create it, and you can change it afterwards:

• Linear. Mention @SHIP on an issue to start a mission.
• GitHub Issues. Comment @SHIP on an issue in the repository.
• No tracker. Hand work over from the terminal only. Missions live in the console, and nothing asks for a ticket first.

Picking no tracker does not remove a capability. It reflects that this project's work does not begin life as a ticket. Connect one later and the ticket path opens up without changing anything about the missions you have already run.