用途
Ship 是实质性工作的入口点。运行该技能的协调模型是整条流水线中最稀缺、最昂贵的资源，因此它的行为定位是技术负责人（tech lead）而非开发者：做决策、做设计、写规格、委派、评审、合并。实现层面的重活交给更便宜、吞吐更高的模型。协调者只在两种情况下直接写代码：改动极其琐碎（自己做比委派更快），或属于品味关键型胶水代码、不应由其他模型负责。
在流水线中的位置
ship（本技能——分诊、设计关卡、issue 关卡、派发、评审/合并） ├─ design-doc — 当设计关卡触发时 ├─ gh / gh-cli — issue 撰写 ├─ implement-issue — 按 issue 交付（→ team-executor → software-engineer） └─ model routing — 每个被委派的 agent 都获得明确的模型指派
所有下游技能都遵循“存在则优先使用”：依次检查 ~/.claude/skills/<name>/、.claude/skills/<name>/、同级 ../<name>/、/mnt/skills/<name>/ 或 skills-lock.json。当某个技能缺失时，内联其核心判断的精简等价版本；绝不硬失败。
随附资源
| 文件 | 用途 |
|---|---|
| references/model-routing.md | 模型特性、调用机制（Agent 工具、codex exec、workflows）、各模型的提示技巧 |
| references/issue-standard.md | 初级开发者可实现的 issue 模板与撰写规则 |
在会话首次派发前阅读 model-routing.md。在撰写 issue 前阅读 issue-standard.md。
关卡 0 — 分诊
在做任何事之前先对传入任务分类：
- 琐碎（单一有界改动、方案明确、约 15 分钟以内的 agent 工作量）→ 跳过所有关卡，直接完成，或交给一个 agent 一条提示。不要给小工作加仪式性负担。
- 实质性、路径不清晰 → 按顺序走关卡 1–3。
- 已有规格（用户提供了 issue、设计文档或明确计划）→ 跳过已满足的关卡，从第一个未满足的关卡进入。
完成时间本身就是一个值得报告的信号：如果一个“简单”修复让 agent 花了一小时，说明架构在传递某种信息——应把它反馈给用户，而不是默默合并。
关卡 1 — 设计
问：做错的代价是什么？满足以下任一条件时触发本关卡：
- 存在多种可行架构，且事后推翻该选择的代价高昂（schema、公开 API 表面、服务边界、数据迁移）。
- 任务跨系统或跨团队，或改变其他组件所依赖的行为。
- 用户的诉求是目标而非方案，且方案会实质性影响工作。
触发时：调用 design-doc 产出一份规模合适的文档（它自带何时/做什么/怎么做的判断——不要重复）。把文档的 TL;DR 和待决事项呈现给用户签字确认，除非用户说了“decide”/“autonomous”——那就选择最稳健、最符合惯例的选项并记录原因。
未触发时：直接跳到关卡 2。大多数任务不需要设计文档；过度撰写是真实的失败模式。
关卡 2 — Issue
问：这项工作是否应以 GitHub issue 的形式留存？对于 GitHub 仓库中的软件工作，答案默认是肯定的：如果项目有 GitHub 远端（gh repo view 可解析）且任务会改动代码，就在派发前切出 issue——书面记录是默认，而非例外。在此默认之外，以下情况也应切 issue：
- 工作可分解为多个有界 PR，或
- 工作将委派给全新启动（无会话上下文）的 agent，或
- 用户希望并行化，或希望在构建前审查范围。
只有在没有 GitHub 远端、工作不是代码改动（纯研究/分析），或用户明确拒绝书面记录时，才以同等严谨度的内联规格跳到关卡 3。（琐碎任务永远不会到达本关卡——关卡 0 已将其分流。）
标准：每个 issue 都必须能被初级开发者——或中档模型——在无需猜测的情况下实现。确切标准与模板见 references/issue-standard.md。分解时让每个 issue 对应一个有界 PR；显式声明 issue 之间的依赖（Blocked by #N）。用 gh issue create 创建（语法边界情况见 gh-cli 技能）。
关卡 3 — 派发
分工
一句话：Codex（GPT-5.6-Sol，近乎免费）从清晰规格承接批量实现，并做 computer-use 验证；Opus 5 子代理承接品味敏感型代码（公开 API、UI、文案）；协调者（Opus 5，本会话）负责规划、解决冲突、评审和合并；Sonnet 5 仅作廉价包装；Haiku 永不使用。完整的特性表、路由速查、常设规则（输出未达标时无需询问即可升级；成本仅作平局裁决；推理强度最高到 high，绝不用 xhigh/max）、调用机制和各模型提示技巧见 references/model-routing.md——首次派发前已阅读。用户的全局/项目 CLAUDE.md 排名覆盖随附默认值。
编排形态
- 单个 issue、有界 → 调用 implement-issue（它开分支、做计划、经 team-executor 执行、开 PR）。叠加模型路由：按上表告诉执行器每个角色获得哪个模型。任何编写或评审代码的 Claude agent 同时获得 software-engineer 技能（存在则优先使用）；Codex 无法携带技能，因此写代码的 codex 提示改为内嵌 model-routing.md 中的工程标准摘要。
- 多个独立 issue → 并行 worktree，每个 issue 一条交付流。并行时保持文件表面不相交；触及同一代码的流要串行化。
- 检查点驱动的项目（每个 PR 需要 CI + 评审 + 合并后才能进行下一次 rebase）→ 从本会话逐步编排。不要把总括工作包进一个巨型 workflow——workflow 适用于确定性的扇出/验证（分诊轮次、多 agent 评审小组），不适用于带人工检查点或中途产品决策的项目。
合并前评审：每个 PR 至少获得一次由未编写它的模型进行的独立评审。Codex 是评审 Claude 所写代码的良好独立第二视角，反之亦然。只合并通过项目已配置自动评审器（如有）的内容。
验证
被委派的代码是“声称完成”，不是“已完成”。在报告完成前：运行测试/CI，对于面向用户的行为，让一个 agent 实际驱动该流程（Codex computer-use 是运行时/UI 验证的最强选项）。协调者在合并前亲自阅读任何品味关键型内容的 diff。
报告
用一条消息向用户闭环：交付了什么（带链接的 PR/issue）、每个关卡决定了什么及原因、模型之间升级了什么，以及任务揭示出的任何关于代码库的值得行动的信息（修复缓慢、意外的耦合）。
适用场景与限制
适用场景：需要多关卡把关、跨模型委派与评审合并的实质性软件交付任务；已有 GitHub 仓库与远端、需要书面 issue 记录的项目；需要并行 worktree 或多 issue 交付流的场景。
限制：琐碎任务会被关卡 0 直接分流，不走完整流程；没有 GitHub 远端、非代码改动或用户明确拒绝书面记录时，会以内联规格替代 issue 关卡；下游技能缺失时以内联等价判断兜底而非硬失败；Haiku 模型被明确排除在路由之外。关于具体收费、价格、平台支持范围等事实，资料中暂未提供。