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 fetches it, follows it, and ends up able to hand work to SHIP on your behalf. Concretely it will:

1. Install the CLI with npm install -g @lets-ship/cli@latest, or upgrade one that has fallen behind.
2. Run ship init, which drops .claude/skills/ship-delegate/SKILL.md into the repository stamped with the installed version, so later sessions load it without fetching and can tell when it has gone stale.
3. Ask you for a token. Creating one is deliberately a human action: an agent cannot mint itself credentials, and the API refuses if it tries.

Everything after that is the agent's to run. You are asked for exactly two things.

The token

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

export SHIP_API_TOKEN=pat_...

For the commands in the skill, the token needs permission to dispatch a mission, read one, and write to one. The console offers those as access levels rather than raw scopes, and the authentication page lists exactly which set fits a coding agent and what to leave out of it.

Bind the token to a single project while you are creating it. A token held by an agent should reach that project and nothing else in your organization.

The account

The token has to belong to an organization with a project in it, which is a one-time pass through the console:

1. Sign in at letsship.ai and create your organization.
2. Install the GitHub App on the repositories SHIP should work in. This one is required, because it is where pull requests land.
3. Add an LLM credential. One is enough to run a whole mission.
4. Create the project, and choose where its work is planned: Linear, GitHub Issues, or no tracker at all. That choice decides whether you get one path or both, and you can change it afterwards, so it is not a decision you have to get right now.

Your first mission

The best first piece of work is the project's own configuration. It is small and safe, and it leaves the project configured rather than just touched.

Ask your agent to write a ship.yml at the repository root declaring which harness and model each role should run on, validated against the published schema. Then hand it over rather than committing it yourself, so you see a full mission end to end:

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

Watch it 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.

Starting from a tracker instead means filing the issue and mentioning @SHIP on it. The console offers that same first mission as a card at the end of onboarding, 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 3 naming a scope, the token exists but was not granted that permission, so create one that has it rather than retrying. Exit 6 means onboarding is not finished, and the message says which 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.