Update to SHIP

{
  "description": "Use when the user wants to hand a plan, a spec or an open pull request to SHIP. It hands work to the SHIP AI agent team from this repository. Delegate a plan or a spec that you wrote, so SHIP builds it. Delegate a branch with an open pull request, so SHIP runs code review and tests on it and makes it ready to merge. For example, the user says \"delegate this\", \"hand this to SHIP\", \"let SHIP build this\", \"let SHIP review this\" or \"ship this spec\". Also use it when the user finishes a plan or a change and asks what to do next.",
  "included_files": [],
  "name": "ship-delegate",
  "skill_md_contents": "---\nname: ship-delegate\ndescription: Use when the user wants to hand a plan, a spec or an open pull request to SHIP. It hands work to the SHIP AI agent team from this repository. Delegate a plan or a spec that you wrote, so SHIP builds it. Delegate a branch with an open pull request, so SHIP runs code review and tests on it and makes it ready to merge. For example, the user says \"delegate this\", \"hand this to SHIP\", \"let SHIP build this\", \"let SHIP review this\" or \"ship this spec\". Also use it when the user finishes a plan or a change and asks what to do next.\n---\n\n# Hand work to SHIP\n\nTwo hand-offs, each one command. SHIP starts a mission for the work, and its agents plan, build, review and test it.\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 delegate plan` | `missions:run` |\n| `ship delegate pr` | `missions:run` |\n\n## When to use it\n\n- The user wrote a plan or a spec and wants SHIP to build it, not you.\n- The user finished code on a branch and wants SHIP to review it, test it and make it ready to merge.\n\nDo not delegate work that you are in the middle of, unless the user asks. Finish or stop first, so that the hand-off\nhas a complete plan or a complete branch. To read the state of a mission or to send it feedback after the hand-off,\nuse the `ship-missions` skill.\n\n## Hand over a plan\n\nWrite the plan to a file first, then delegate it. SHIP skips its own Planner and builds from your spec as you wrote it.\n\n```bash\n# For an issue that already exists\nship delegate plan SHIP-412 --file docs/plan.md\n\n# No issue yet: create one and start the mission in the same call\nship delegate plan --title \"Rate-limit the search endpoint\" --file docs/plan.md\n```\n\nIf you know the files that the plan changes, name them with `--file-plan <path.json>`. The file is a JSON array of\n`{path, action, description}`. Without it, the Builder chooses the files.\n\n## Hand over a branch\n\nOpen the pull request yourself, then delegate it. SHIP never pushes a branch or opens a pull request for you. If the\n`gh` CLI is available, the command reads `--pr` from the current branch.\n\n```bash\nship delegate pr SHIP-412              # review, then test, then merge\nship delegate pr SHIP-412 --at qa      # already reviewed: only test it\nship delegate pr                       # no issue: SHIP names the mission after the pull request\n```\n\nIf CI fails on that pull request, SHIP fixes the failure before the review. That is expected, not an error.\n\n## Choose the harness, model or sandbox for one mission\n\nThese flags change how this one mission runs. They take priority over the `ship.yml` of the project and do not change\nthe file. They apply to the role that the mission starts at: the Builder for `delegate plan`, and the Reviewer or the\nQA agent for `delegate pr`.\n\n```bash\nship delegate plan SHIP-412 --file docs/plan.md --harness codex\nship delegate plan SHIP-412 --file docs/plan.md --model opus\nship delegate pr SHIP-412 --at qa --harness open-code --model z-ai/glm-5.2\nship delegate plan SHIP-412 --file docs/plan.md --sandbox python-uv --size standard-2\n```\n\nThe harnesses are `claude-code`, `codex`, `pi`, `kilo-code` and `open-code`. You can give `--model` without\n`--harness`, and the configured harness stays. `--sandbox` names a custom sandbox (see the `ship-sandboxes` skill), and\n`--size` sets the machine size for this mission.\n\nUse these flags when the user asks for a specific agent, model or sandbox, or to compare two of them on the same work.\nOtherwise, leave them out. The configuration of the project is the setting that the team agreed on.\n\n## The configuration of the project\n\nThat configuration is `ship.yml` at the root of the repository. It sets the harness and the model of each role. It\nalso sets how long the retry loop continues, where a preview environment deploys, and how QA tests a change that has no\npreview URL.\n\nThe published JSON Schema is the source of truth for its shape:\n\n```\nhttps://letsship.ai/schema/ship.yml.json\n```\n\nWhen you write or change the file, put the modeline on the first line, so that an editor validates the file. Then\nvalidate the file against the schema before you hand anything over:\n\n```yaml\n# yaml-language-server: $schema=https://letsship.ai/schema/ship.yml.json\nversion: 1\ndeployments: {}\n```\n\n`version` and `deployments` are both required. A project that has nothing to preview writes `deployments: {}` and keeps\nthe key. If the file fails validation, SHIP ignores all of it, and `agents` and `retries` go back to the platform\ndefaults. The full field reference is at <https://letsship.ai/docs/configuration/schema>.\n\nA change to `ship.yml` is normal work in the repository: a branch and a pull request, or a mission that you delegate.\nThe flags in this skill never write to the file.\n\n## Give one role extra instructions for one mission\n\nWhen the user wants this mission built or judged in a different way, send the instructions with the hand-off. Examples\nare \"review it for security\" or \"keep the public API stable\". Do not put them in the issue text. They apply to the role\nthat the mission starts at, for this mission only, and SHIP commits nothing to the repository.\n\n```bash\nship delegate pr SHIP-412 --prompt-file security-review.md\nship delegate pr SHIP-412 --prompt-path .ship/lanes/security.md\n```\n\nTo give the instructions to a different role, add `--prompt-role planner|builder|reviewer|qa`. The `--prompt-file`,\n`--prompt-path`, `--prompt-mode` and `--prompt-role` flags also work on `ship mission create` and `ship mission start`,\nwhere the mission starts at the Planner. The delegate commands skip the Planner, so they refuse `--prompt-role planner`.\nA restart of a mission with an open pull request also skips the Planner, so name the role with `--prompt-role` there.\n\n```bash\nship mission start SHIP-412 --prompt-file plan-notes.md\nship delegate pr SHIP-412 --prompt-role qa --prompt-file qa-notes.md\n```\n\nWrite the instructions to a file first, the same way as a plan. `--prompt-path` names a file that is already in the\nrepository. Add `--prompt-ref` to read that file at a specific git ref.\n\n`--prompt-mode` decides what happens to the own instructions of the repository for that role, in\n`.ship/agents/<role>.md`:\n\n| Mode | Effect |\n| --- | --- |\n| `replace` (default) | Your instructions are the only project instructions for the role. SHIP does not read the file of the repository. |\n| `extend` | SHIP reads the file of the repository first and adds your instructions after it. |\n\n```bash\nship delegate pr SHIP-412 --prompt-file security-review.md --prompt-mode extend\n```\n\nUse `extend` when you add a concern, such as a security review or one more rule. The `replace` mode drops the\nconventions that the repository wrote for the role, and the user almost never wants that. Use `replace` only for a\nmission that is a different job from the normal work, or when the user tells you to ignore the file. The SHIP charter\nfor the role applies in both modes.\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 `missions:run`. | Ask the user for a token with the scope. Do not retry. |\n| 4 | SHIP found no such issue or project. | Check the issue id, or give `--project <id>`. |\n| 5 | The hand-off needs something that is not true yet, for example a review with no pull request. | Do what the message says, then run the command again. |\n| 6 | The organization did not finish the onboarding. | Ask the user to finish it in the console. |\n"
}