Update to SHIP

{
  "description": "Use when the user wants to follow a SHIP mission, check its status, or pass it feedback, review comments or a decision while it runs. It follows, controls and finishes the SHIP missions that you or the user started. List missions, read the state of one, and send it instructions or feedback. Pause, resume, stop, restart, merge or decline a mission, approve a checkpoint or a credit limit, and read its preview, proof and credits. For example, the user asks \"what is the status of SHIP-412\", \"is SHIP done with it\" or \"tell SHIP to change X\". Also use it when the user says \"pause that mission\" or \"merge it\", or asks for a change in one line.",
  "included_files": [],
  "name": "ship-missions",
  "skill_md_contents": "---\nname: ship-missions\ndescription: Use when the user wants to follow a SHIP mission, check its status, or pass it feedback, review comments or a decision while it runs. It follows, controls and finishes the SHIP missions that you or the user started. List missions, read the state of one, and send it instructions or feedback. Pause, resume, stop, restart, merge or decline a mission, approve a checkpoint or a credit limit, and read its preview, proof and credits. For example, the user asks \"what is the status of SHIP-412\", \"is SHIP done with it\" or \"tell SHIP to change X\". Also use it when the user says \"pause that mission\" or \"merge it\", or asks for a change in one line.\n---\n\n# Follow and steer a mission\n\nA mission is the work that SHIP does for one issue. Use this skill after a hand-off (see the `ship-delegate` skill), to\nread the state of a mission, to send it new information and to finish it. To read what one agent did inside a mission,\nuse the `ship-agent-runs` skill.\n\nThis skill needs the `ship` CLI and a `SHIP_API_TOKEN`. If you do not have them, do the setup at\n<https://letsship.ai/SKILL.md> first. If this file has no `version` in its frontmatter, you read the hosted copy, so do\nthe setup too. If its `version` is older than `ship --version`, run `ship init --force`.\n\n| Command | Token scope |\n| --- | --- |\n| `ship status`, `ship mission list` | `missions:read` |\n| `ship instruct`, `ship mission pause`, `ship mission resume`, `ship mission stop` | `missions:write` |\n| `ship mission merge`, `ship mission decline`, `ship mission auto-merge` | `missions:write` |\n| `ship mission archive`, `ship mission unarchive`, `ship mission disposition` | `missions:write` |\n| `ship mission create`, `ship mission start`, `ship mission approve-ceiling` | `missions:run` |\n| `ship mission override get` | `agents:read` |\n| `ship mission override set` | `agents:read` and `agents:write` |\n| `ship mission override clear` | `agents:write` |\n| `ship mission inspect` | `inspect:read` |\n| `ship preview list`, `ship preview get` | `environments:read` |\n| `ship preview destroy` | `environments:write` |\n| `ship artifact list`, `ship artifact get` | `artifacts:read` |\n| `ship credits`, `ship credits offers`, `ship credits request`, `ship setup`, `ship notice list`, `ship notice dismiss` | any token |\n| `ship credits ledger`, `ship credits buy`, `ship credits plan` | any token, with an owner or admin behind it |\n\nThe controls also need a role in the organization that can control missions. Archive and disposition need an owner or\nan admin. Without `--project`, the override commands read the project from the mission, so the token also needs\n`missions:read`. A token never has more access than the person who created it.\n\n## See the missions\n\n```bash\nship mission list\nship mission list --activity needs_attention\nship mission list --search \"rate limit\" --json\nship mission list --project prj_123 --offset 25\n```\n\nThe list shows each mission with what it does now, its stage and its pull request. The `--activity` flag takes the\nvalues of the status filter in the console, for example `building`, `reviewing`, `testing`, `ready_to_merge`,\n`needs_attention` or `paused`. The list covers every project of the token, unless `--project` names one.\n`SHIP_PROJECT_ID` does not narrow a list. When more missions match, the last line gives the `--offset` of the next\npage.\n\n## Read the state of a mission\n\n```bash\nship status SHIP-412\nship status SHIP-412 --json    # for jq\n```\n\nThe command prints the stage of the mission, its review state, its test state and its pull request. It also lists the\nagent runs of the mission, and the run whose artifacts are the proof of the work. Read it before you tell the user that\nwork is complete.\n\n## Start a mission from a request\n\nWhen the user asks for a change in one line and there is no plan or branch yet, let SHIP plan it:\n\n```bash\nship mission create --title \"Fix the login redirect\" --description \"- [ ] Login returns to the page it came from\"\nship mission start SHIP-412 --project prj_123\n```\n\n`ship mission create` files the issue and starts the mission at the Planner. Write the acceptance criteria as\ncheckboxes, because the QA agent tests against them. `ship mission start` starts a mission on an issue that is already\nin the tracker. When the user has a plan or a branch, use the `ship-delegate` skill instead.\n\n## Send feedback to a mission\n\nWhen the user decides something about work that SHIP already has, send it as an instruction. Examples are an answer to\na question from the agents, review comments, or a correction to a choice that an agent made. The instruction goes to\nthe agents and starts the Builder on the open pull request of the mission.\n\n```bash\nship instruct SHIP-412 -m \"Keep the current Node range. Override nopt instead.\"\nship instruct SHIP-412 --file review-notes.md\nship instruct SHIP-412 -m \"FYI staging is down until 14:00\" --note\n```\n\n`--note` records context for the next agent and starts no work. Use it for background information. Leave it out for\nanything that you want the agents to act on.\n\nUse an instruction, not a new hand-off or a restart. A restart checks the same pull request against the review and test\nresults that it already has. It finds no change and correctly does nothing, so the feedback goes nowhere. An instruction\nis the channel for new information.\n\nThe reply tells you what SHIP recorded and what it starts:\n\n```\nSHIP-412  instruction recorded (ins_9b8e2a3f3c4d)\n  mission   ready_to_merge\n  dispatch  builder: it will pick this up on the mission's open pull request\n```\n\nWhen SHIP starts no work, the reply says why and what to do instead. An example is a pull request that is already\nmerged: the remedy is a new mission, not feedback to a finished one. Read that line before you report back. Do not tell\nthe user that an instruction arrived until the reply says `recorded`.\n\n## Pause, resume or stop a mission\n\n```bash\nship mission pause SHIP-412\nship mission resume SHIP-412\nship mission stop SHIP-412\n```\n\nA pause lets the current stage finish, then holds the mission before its next stage. A resume continues it. A stop ends\nevery agent of the mission, and their work in progress is lost. The pull request stays open. Pause or stop a mission\nonly when the user asks for it.\n\nA checkpoint in `ship.yml` pauses a mission after a stage, so that a person can read the result first. `ship status`\nthen shows `paused yes (checkpoint:<role>)`. When the user approves the result, resume the mission. When the user wants\nchanges to the result, send an instruction instead.\n\n## Change the agents of one mission\n\nAn override changes the harness, the model or another setting of one role, for one mission only. Each field replaces\nthe same field of `ship.yml`, and the file itself does not change. The next run of that role uses the override.\n\n```bash\nship mission override get SHIP-412\nship mission override set SHIP-412 --role reviewer --harness codex --model gpt-5.5\nship mission override set SHIP-412 --role builder --checkpoint on\nship mission override set SHIP-412 --role qa --prompt-file qa-notes.md --prompt-mode extend\nship mission override set SHIP-412 --role builder --harness codex --unset model\nship mission override clear SHIP-412\n```\n\nThe action `set` changes only the role that `--role` names, and only the settings that you give. The other roles and\nsettings of the override stay. The flag `--checkpoint on` pauses the mission after that stage, so that a person reads\nthe result first. The flag `--reject-on` sets the lowest finding that makes the reviewer ask for changes. The flag\n`--base-branch` sets the branch that the mission starts from. The flag `--unset` removes stored fields, for example the\nmodel when you change the harness, and the action `clear` removes the whole override.\n\nChange an override only when the user asks for it, because a different model can change the cost of the mission.\nWithout `--project`, the command reads the project from the mission. The variable `SHIP_PROJECT_ID` does not apply to\nan override, because an override saved for the wrong project changes no run.\n\n## Auto-merge, archive and disposition\n\n```bash\nship mission auto-merge SHIP-412 on\nship mission auto-merge SHIP-412 off\nship mission archive SHIP-412\nship mission unarchive SHIP-412\nship mission disposition SHIP-412 superseded --superseded-by SHIP-420\n```\n\nWith auto-merge on, SHIP merges the pull request of the mission when the checks, the review and the test pass, and no\nperson merges it. For this mission, the setting replaces the auto-merge of the project. Turn it on only when the user\nasks for it.\n\nAn archived mission is not on the board and not in `ship mission list`. The disposition records why a mission ended,\nfor the delivery statistics: `product`, `probe`, `superseded`, `takeover`, or `none` to clear it. Record only what\nthe user decided, never your own guess.\n\n## Restart a mission\n\nA mission that stopped, failed or needs attention does not start again on its own. When the user asks for a new\nattempt, start it again:\n\n```bash\nship mission start SHIP-412 --project prj_123\n```\n\nRead `ship mission inspect` first if you must find why the last attempt failed. It needs the `inspect:read` scope.\n\n```bash\nship mission inspect SHIP-412 --sections taskState,retryReason\n```\n\n## Let a mission continue past its credit limit\n\nEach mission can use a fixed number of credits. At that limit, the mission pauses until a member lets it continue.\n`ship status` and `ship notice list` show it. When the user agrees to the extra cost, run:\n\n```bash\nship mission approve-ceiling SHIP-412 --project prj_123\n```\n\nThe command raises the limit of the mission by one step, and the stage that stopped runs again. Without `--project` or\n`SHIP_PROJECT_ID`, the command reads the project from the mission, so the token also needs `missions:read`. Check the balance\nwith `ship credits` before and after work:\n\n```bash\nship credits\nship notice list\nship notice dismiss credits_low:grant_123\n```\n\nThe notices show what needs attention in the organization, such as a tracker to connect again or credits that run low.\nYou can close a warning with `ship notice dismiss`. A critical notice stays until someone fixes its cause.\n\n## Credits\n\n```bash\nship credits ledger\nship credits ledger --limit 100 --cursor eyJhIjoxfQ\nship credits offers\nship credits request -m \"Two more missions for the release this week\"\n```\n\nThe ledger shows where the credits went, newest first: each mission and the credits that it used, each grant, each\nadjustment and each expiry. When more entries exist, the last line gives the `--cursor` for the next page. The offers\nare the credit packs, the monthly plans and Enterprise, with their prices. A credit request goes to SHIP or to the\nowners and admins of the organization, and the reply says which.\n\nBuy credits or change the plan only when the user asks you to:\n\n```bash\nship credits buy credit_pack_50 --start-now\nship credits buy team --plan starter --start-now\nship credits plan scale\nship credits plan --cancel\n```\n\nThe command `ship credits buy` prints the address of a payment page and charges nothing. Give that address to the user,\nwho pays there. Without `--start-now`, the command shows the text of the consent to start the credits at once, and\nstops. Show that text to the user, and add `--start-now` only when the user agrees to it. The command\n`ship credits plan` changes the monthly plan from the next renewal. With `--cancel`, the plan ends at the end of the\nmonth that the user paid for.\n\n## Check the preview and the proof\n\n```bash\nship preview list --mission SHIP-412\nship artifact list --mission SHIP-412\nship artifact list --run qa-ship-412-77d0e2c1-qa-1\n```\n\nSHIP deploys a preview of the pull request through the delivery pipeline of the repository, and the QA agent tests it.\nThe proof of a mission is the artifacts of the QA run that passed: traces, screenshots, videos and logs. The command\n`ship status` names that run, so give its id to `--run`. Each artifact has a link that opens it. Give these links to the\nuser when they ask for evidence.\n\n`ship preview destroy` removes a preview before it expires. Use it only when the user asks for it.\n\n## Merge or decline the pull request\n\n```bash\nship mission merge SHIP-412\nship mission decline SHIP-412\n```\n\nMerge or decline only when the user tells you to. The merge uses the merge method of the repository, and then the\nmission becomes done. If the pull request cannot merge, the command exits 5 with the reason. On a merge conflict, SHIP\nalso starts the Builder to fix the conflict, and it merges the pull request when the mission is ready again. Do not\nmerge again, and tell the user that the Builder works on the conflict. The decline closes the pull request without a\nmerge, and you cannot undo it.\n\n## Exit codes\n\nEvery command also takes `--json`, which prints the raw API response.\n\n| Exit code | Meaning | What to do |\n| --- | --- | --- |\n| 2 | The arguments are wrong. The message names the problem. | Fix the command. |\n| 3 | The token is not set, or it does not have the scope of the command, or the role cannot do it. | Ask the user for a token with the scope. Do not retry. |\n| 4 | SHIP found no such mission, project, preview or artifact. | Check the issue id or the other id, or give `--project <id>`. |\n| 5 | The mission is not in a state that allows the action, or the organization has no credits. | Read the message, then `ship status`. Do what the message says. |\n| 6 | The organization did not finish the onboarding. | Ask the user to finish it in the console. |\n| 8 | Too many requests, or the organization reached a daily limit. | Wait, then run the command again. Tell the user about a daily limit. |\n"
}