Set up

Point your agent at the skill

Give your coding agent this line:

set up https://letsship.ai/SKILL.md

That URL serves a skill. Your agent reads the skill and follows it, and after that it can hand work to SHIP for you. The agent does these steps:

1. Install the CLI with npm install -g @lets-ship/cli@latest, or upgrade an installed CLI that is out of date.
2. Run ship init. This command writes .claude/skills/ship-delegate/SKILL.md into the repository and stamps it with the installed version. Later sessions load the skill from that file and do not fetch it again. They can also tell when the file is out of date.
3. Ask you for a token. Only a person can create one. An agent cannot create credentials for itself, and the API refuses if it tries.

The agent runs everything after that. It needs exactly two things from you.

The token

Create a personal access token in the console under Settings → API tokens, then export it:

export SHIP_API_TOKEN=pat_...

The commands in the skill need a token that can dispatch a mission, read a mission and write to a mission. The console shows these permissions as access levels, not raw scopes. The authentication page lists which set fits a coding agent and what to leave out.

When you create the token, bind it to a single project. A token that an agent holds should reach that project and nothing else in your organization.

The account

The token must belong to an organization that has a project. You set this up one time in the console:

1. Sign in at letsship.ai. Then create your organization.
2. Install the GitHub App on the repositories SHIP should work in. You must do this step, because SHIP opens its pull requests in those repositories.
3. Add an LLM credential. One is enough to run a whole mission.
4. Create the project. Choose where you plan its work: Linear, GitHub Issues or no tracker at all. That choice decides whether you get one path or both. You can change it later, so you do not have to get it right now.

Your first mission

The best first piece of work is the project's own configuration. It is small and safe, and the result is a configured project, not a test change.

Ask your agent to write a ship.yml at the repository root. The file sets the harness and model for each role, and it must validate against the published schema. Do not commit the file yourself. Hand it over instead, so you see a full mission end to end:

ship delegate plan --title "Add ship.yml configuration" --file docs/ship-yml-plan.md

Watch the mission on the board in the console. The mission plans, builds, runs your CI, reviews its own diff and opens a pull request for you to merge.

To start from a tracker instead, file the issue and mention @SHIP on it. At the end of onboarding, the console shows the same first mission as a card that is already written for you.

Verify it worked

ship status <ISSUE>            # the mission's current state
ship status <ISSUE> --json     # same, for piping into jq

If a command exits with 3 and names a scope, the token is valid but does not have that permission. Create a new token that has the permission. Do not only retry the command. Exit 6 means that onboarding is not finished, and the message names the step.

Next

• Ways of working covers the two paths and how they combine.
• CLI documents every command, flag and exit code.
• Configuration is the full ship.yml field reference.